4 ms·

I understand what you're saying. It would be better to just talk about the enforced separation between pure code and code with side-effects, and explain that it

I understand what you're saying. It would be better to just talk about the enforced separation between pure code and code with side-effects, and explain that it's possible to structure a normal program so that it's mostly pure.

seanmcdirmid 13y ago
You are just making a claim though, no one know if it is actually true. Semantic purity doesn't necessarily lead to human clarity, which is one of the mountains Haskell has had to climb: it doesn't seem "easier" or "more simple" than other approaches, only claims of safety might hold up to some scrutiny.
- tome 13y ago
  As a day-to-day Haskell programmer I'm happy to say that purity makes it easier to understand the programs that I write. Still, you're welcome to suggest that's an entirely subjective anecdote if you like.
  - seanmcdirmid 13y ago
    You'd think that an empirical experiment with new programmers could prove the point, or at least provide conclusive evidence.
    - tome 13y ago
      Personally I wouldn't think that. I think that such things are far too complicated to be amenable to scientific study.
      - seanmcdirmid 13y ago
        I would normally agree, but specific usability claims are being made continuously about the benefits of purity, while many programmers think of Haskell has being anything but.
- mercurial 13y ago
  You will note that I make no claims about clarity, only that it is possible to separate pure from impure code in Haskell (which is certainly true). The problem with Haskell and clarity are, in my experience, twofold: - large amount of high-level concepts to absorb (though not everything is necessary to start producing code) - the power of the language is its own worst enemy at times - it is possible to write a pipeline of complex computation with very little work, which leads to less code but less readability (on the other hand, Haskell functions are typically short, which helps a lot with maintaining up-to-date comments) On the other hand, the separation between pure and impure code is not a complex notion per se, and reasoning about pure code is made much easier.
  - seanmcdirmid 13y ago
    Right. It is quite easy to build convoluted Haskell code just as it is easy to to build convoluted Java code. One of my primary complaints about Haskell, however, is that Haskell code is impossible to debug. You can reason about it, the type checkers can check deep properties about it, but it is difficult to actually observe the computer executing it! To me, this is a deal breaker.
    - gizmo686 13y ago
      Have you looked into Debug.trace? The type of trace is "String -> a -> a". This is a 'pure' function that 'ignores' the first argument and returns the second unmodified. What actually happens is that the first argument is a String that gets printed to stdout. Furthermore, once you give it the first argument, it is simply the identity function, which allows you to easily place it anywhere in you code. For example, if you have a function: add x y = x+y, and you wanted to see all of the inputs add gets, you could do: add x y = trace (show (x,y)) $ x+y. For anyone confused about how such a function is possible in Haskell, not that it is in Debug, and the documentation clearly states that it should only be used for debugging. EDIT: You could also do traceShow (x,y) $ x+y.
      - seanmcdirmid 13y ago
        I've seen this, it basically allows us to generate execution trace trees, which is quite trivial in most languages must somehow hard in Haskell. I've studied a lot of mechanisms for debugging Haskell code, and some of the debugging mechanisms taken for granted in other languages can be clawed back. But at the end of the day, it is a struggle: the purity (or more accurately, laziness) that is supposed to help so much ends up hurting in at least one aspect. Perhaps why Haskell programs are so easy to reason about statically is because they are so hard to reason about dynamically :)

seanmcdirmid 13y ago

You are just making a claim though, no one know if it is actually true. Semantic purity doesn't necessarily lead to human clarity, which is one of the mountains Haskell has had to climb: it doesn't seem "easier" or "more simple" than other approaches, only claims of safety might hold up to some scrutiny.

tome 13y ago
As a day-to-day Haskell programmer I'm happy to say that purity makes it easier to understand the programs that I write. Still, you're welcome to suggest that's an entirely subjective anecdote if you like.
- seanmcdirmid 13y ago
  You'd think that an empirical experiment with new programmers could prove the point, or at least provide conclusive evidence.
  - tome 13y ago
    Personally I wouldn't think that. I think that such things are far too complicated to be amenable to scientific study.
    - seanmcdirmid 13y ago
      I would normally agree, but specific usability claims are being made continuously about the benefits of purity, while many programmers think of Haskell has being anything but.
mercurial 13y ago
You will note that I make no claims about clarity, only that it is possible to separate pure from impure code in Haskell (which is certainly true). The problem with Haskell and clarity are, in my experience, twofold: - large amount of high-level concepts to absorb (though not everything is necessary to start producing code) - the power of the language is its own worst enemy at times - it is possible to write a pipeline of complex computation with very little work, which leads to less code but less readability (on the other hand, Haskell functions are typically short, which helps a lot with maintaining up-to-date comments) On the other hand, the separation between pure and impure code is not a complex notion per se, and reasoning about pure code is made much easier.
- seanmcdirmid 13y ago
  Right. It is quite easy to build convoluted Haskell code just as it is easy to to build convoluted Java code. One of my primary complaints about Haskell, however, is that Haskell code is impossible to debug. You can reason about it, the type checkers can check deep properties about it, but it is difficult to actually observe the computer executing it! To me, this is a deal breaker.
  - gizmo686 13y ago
    Have you looked into Debug.trace? The type of trace is "String -> a -> a". This is a 'pure' function that 'ignores' the first argument and returns the second unmodified. What actually happens is that the first argument is a String that gets printed to stdout. Furthermore, once you give it the first argument, it is simply the identity function, which allows you to easily place it anywhere in you code. For example, if you have a function: add x y = x+y, and you wanted to see all of the inputs add gets, you could do: add x y = trace (show (x,y)) $ x+y. For anyone confused about how such a function is possible in Haskell, not that it is in Debug, and the documentation clearly states that it should only be used for debugging. EDIT: You could also do traceShow (x,y) $ x+y.
    - seanmcdirmid 13y ago
      I've seen this, it basically allows us to generate execution trace trees, which is quite trivial in most languages must somehow hard in Haskell. I've studied a lot of mechanisms for debugging Haskell code, and some of the debugging mechanisms taken for granted in other languages can be clawed back. But at the end of the day, it is a struggle: the purity (or more accurately, laziness) that is supposed to help so much ends up hurting in at least one aspect. Perhaps why Haskell programs are so easy to reason about statically is because they are so hard to reason about dynamically :)