3 ms·

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

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 :)
    - Peaker 13y ago
      Your last point is the other way around: Haskell has excellent static reasoning/debugging facilities therefore there is little pressure to make good debugging tools. I believe purity should make debugging easier, not harder. Laziness should only make performance debugging harder, not correctness debugging. There is much room for improvement in this space.
- deleted 13y ago
  [deleted]
- tome 13y ago
  > Right. It is quite easy to build convoluted Haskell code just as it is easy to to build convoluted Java code. I don't think it's quite as easy, but I'll concede the point so I can make the more important point: it is much easier to write clear Haskell code than clear Java code (at least, "clear" as I understand clarity, YMMV). > 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! Certainly purity makes it hard to observe, and laziness makes it hard to understand how the program executes. However purity also means that static debugging (e.g. QuickCheck) is far more powerful than in other languages so dynamic debugging (actually watching your running program) is less needed. In fact I do far less debugging in Haskell than in Python, say. I first fight the compiler. When I win, the end result is correct more often in Haskell than in any other language I've ever used. > To me, this is a deal breaker. That's fair enough. Everyone has their own preferences. Personally I've never noticed it be a problem. Disclaimer: I don't write performance sensitive code. I expect performance tuning in Haskell is harder than what I've described above.
  - seanmcdirmid 13y ago
    > I first fight the compiler. When I win, the end result is correct more often in Haskell than in any other language I've ever used. And now we get to a few of questions related to bias: * Given that debugging is difficult in Haskell, do Haskell programmers to get in the habit of statically debugging their code? Is that really more "better" than dynamic debugging? Some type error messages in languages like Scala and Haskell can make static debugging quite painful. * Does Haskell's powerful type system bias it to well understood problems with meaningful types? I attended a WGFP meeting once, and it was amazing to hear people like SPJ talk about how they found elegant solutions to icky programming problems, but I thought that, given a dirtier language, you could just write a dirty solution and be done with it. * Would Python's dynamic type system make it more suited to problems with dirtier less clear types when compared to Haskell? If you know both Haskell and Python, do you divide your potential programs into "Python programs" and "Haskell programs"? * When one writes Haskell code, do they really not have to debug and test their code?
    - 13y ago
- Peaker 13y ago
  You're overstating it. Debugging Haskell code is definitely harder than in other languages. But it's far from impossible (I use Debug.Trace successfully), and you do it far less often. So debugging takes 5 times more effort but needs to be done 15 times less than in other languages. At least that's the deal I'm getting and I don't usually find myself debugging much so it's not a grave concern. I'd say lack of non nullability or pattern matching are worse show stoppers.
deleted 13y ago
[deleted]

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 :)
  - Peaker 13y ago
    Your last point is the other way around: Haskell has excellent static reasoning/debugging facilities therefore there is little pressure to make good debugging tools. I believe purity should make debugging easier, not harder. Laziness should only make performance debugging harder, not correctness debugging. There is much room for improvement in this space.
deleted 13y ago
[deleted]
tome 13y ago
> Right. It is quite easy to build convoluted Haskell code just as it is easy to to build convoluted Java code. I don't think it's quite as easy, but I'll concede the point so I can make the more important point: it is much easier to write clear Haskell code than clear Java code (at least, "clear" as I understand clarity, YMMV). > 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! Certainly purity makes it hard to observe, and laziness makes it hard to understand how the program executes. However purity also means that static debugging (e.g. QuickCheck) is far more powerful than in other languages so dynamic debugging (actually watching your running program) is less needed. In fact I do far less debugging in Haskell than in Python, say. I first fight the compiler. When I win, the end result is correct more often in Haskell than in any other language I've ever used. > To me, this is a deal breaker. That's fair enough. Everyone has their own preferences. Personally I've never noticed it be a problem. Disclaimer: I don't write performance sensitive code. I expect performance tuning in Haskell is harder than what I've described above.
- seanmcdirmid 13y ago
  > I first fight the compiler. When I win, the end result is correct more often in Haskell than in any other language I've ever used. And now we get to a few of questions related to bias: * Given that debugging is difficult in Haskell, do Haskell programmers to get in the habit of statically debugging their code? Is that really more "better" than dynamic debugging? Some type error messages in languages like Scala and Haskell can make static debugging quite painful. * Does Haskell's powerful type system bias it to well understood problems with meaningful types? I attended a WGFP meeting once, and it was amazing to hear people like SPJ talk about how they found elegant solutions to icky programming problems, but I thought that, given a dirtier language, you could just write a dirty solution and be done with it. * Would Python's dynamic type system make it more suited to problems with dirtier less clear types when compared to Haskell? If you know both Haskell and Python, do you divide your potential programs into "Python programs" and "Haskell programs"? * When one writes Haskell code, do they really not have to debug and test their code?
  - 13y ago
Peaker 13y ago
You're overstating it. Debugging Haskell code is definitely harder than in other languages. But it's far from impossible (I use Debug.Trace successfully), and you do it far less often. So debugging takes 5 times more effort but needs to be done 15 times less than in other languages. At least that's the deal I'm getting and I don't usually find myself debugging much so it's not a grave concern. I'd say lack of non nullability or pattern matching are worse show stoppers.

deleted 13y ago

[deleted]