4 ms·

The example didn't really intend to show off a particular behavior but instead the interweaving of effects. Indeed. My point was not to nitpick an interesting

The example didn't really intend to show off a particular behavior but instead the interweaving of effects. Indeed. My point was not to nitpick an interesting article. I was trying to illustrate how making so many details explicit in Haskell has a real, practical downside: what seems to be an obvious logic error had slipped through, where it surely would have been spotted easily in the simpler Python code. Moreover, no-one had even mentioned this possible bug after a couple of hours and dozens of posts here, though of course that could just be because no-one else felt this point was important enough to make rather than because they hadn’t noticed.

dllthomas 13y ago
FWIW, I tend to prefer using modify rather than set wherever that makes sense, which would make this particular bug harder to express.
- tel 13y ago
  Yeah. I didn't follow your point since I didn't feel like this was a terrifically idiomatic example. I felt like the bug was equally easy to catch in either expression.
nightski 13y ago
No offense but you failed miserably. If you were trying to reproduce the python code in Haskell, the example is not what you would write. This is a 1 liner in Haskell. The two examples do not represent the same thing.
- Chris_Newton 13y ago
  The two examples do not represent the same thing. This is a claim I don’t understand. They are both simple examples of representing an algorithm that maintains state in their respective languages. Of course you could write it as a one-liner using a different style in Haskell, and in various imperative languages for that matter. However, my point was that making these monadic abstractions explicit everywhere in Haskell does add weight to the code. That continues to be true for more complicated stateful code that can’t be rewritten as a one-liner or expressed more elegantly using recursion anyway.
  - asdasf 13y ago
    It is made explicit and verbose in that contrived example because it specifically an example of those things. I am having a really hard time believing that you genuinely don't understand this obvious fact.
    - Chris_Newton 13y ago
      Of course I understand that this is a contrived example. What I don’t accept — without evidence to the contrary — is that it is unrepresentative. Would more “serious” examples of implementing stateful algorithms using monads and similar tools not be similarly verbose, given the explicit nature of such details in Haskell? Maybe that really is true for experts, in which case I would be happy to learn about it and update my views. Examples are welcome. For now, I have never personally seen it, and it’s not immediately obvious to me how Haskell code would beat a dedicated imperative language at its own game in terms of conciseness. Correctness guarantees, sure. Performance, maybe, if we reach the point where powerful optimisations are possible in Haskell because of the extra information available. And for conciseness, I’m not suggesting it’s orders of magnitude worse or anything silly like that. But when, by design, your effects and sequencing have to be singled out and specified explicitly every time, you’re starting at a disadvantage compared to systems that incorporate that behaviour implicitly. Please also see my comments on quicksort elsewhere in this thread.
  - nightski 13y ago
    I simply do not agree that the abstractions add weight to the code. If anything I think that they make it more concise. It scales much better than constructs given to you in Python. But don't take my word for it, try writing a complicated Haskell program with lots of effects. I think you will find the capability Haskell provides to compose and abstract a huge boon.
    - Chris_Newton 13y ago
      But don't take my word for it, try writing a complicated Haskell program with lots of effects. Unfortunately it’s late and I don’t have time to spend the next few weeks writing Haskell code to try your experiment. I’m guessing no-one else reading this does either. Perhaps you could instead direct us all to some existing projects that demonstrate the advantages you’re describing, so we could see the kind of code you’re thinking of and make up our own minds?

dllthomas 13y ago

FWIW, I tend to prefer using modify rather than set wherever that makes sense, which would make this particular bug harder to express.

tel 13y ago
Yeah. I didn't follow your point since I didn't feel like this was a terrifically idiomatic example. I felt like the bug was equally easy to catch in either expression.

nightski 13y ago

No offense but you failed miserably. If you were trying to reproduce the python code in Haskell, the example is not what you would write. This is a 1 liner in Haskell. The two examples do not represent the same thing.

Chris_Newton 13y ago
The two examples do not represent the same thing. This is a claim I don’t understand. They are both simple examples of representing an algorithm that maintains state in their respective languages. Of course you could write it as a one-liner using a different style in Haskell, and in various imperative languages for that matter. However, my point was that making these monadic abstractions explicit everywhere in Haskell does add weight to the code. That continues to be true for more complicated stateful code that can’t be rewritten as a one-liner or expressed more elegantly using recursion anyway.
- asdasf 13y ago
  It is made explicit and verbose in that contrived example because it specifically an example of those things. I am having a really hard time believing that you genuinely don't understand this obvious fact.
  - Chris_Newton 13y ago
    Of course I understand that this is a contrived example. What I don’t accept — without evidence to the contrary — is that it is unrepresentative. Would more “serious” examples of implementing stateful algorithms using monads and similar tools not be similarly verbose, given the explicit nature of such details in Haskell? Maybe that really is true for experts, in which case I would be happy to learn about it and update my views. Examples are welcome. For now, I have never personally seen it, and it’s not immediately obvious to me how Haskell code would beat a dedicated imperative language at its own game in terms of conciseness. Correctness guarantees, sure. Performance, maybe, if we reach the point where powerful optimisations are possible in Haskell because of the extra information available. And for conciseness, I’m not suggesting it’s orders of magnitude worse or anything silly like that. But when, by design, your effects and sequencing have to be singled out and specified explicitly every time, you’re starting at a disadvantage compared to systems that incorporate that behaviour implicitly. Please also see my comments on quicksort elsewhere in this thread.
- nightski 13y ago
  I simply do not agree that the abstractions add weight to the code. If anything I think that they make it more concise. It scales much better than constructs given to you in Python. But don't take my word for it, try writing a complicated Haskell program with lots of effects. I think you will find the capability Haskell provides to compose and abstract a huge boon.
  - Chris_Newton 13y ago
    But don't take my word for it, try writing a complicated Haskell program with lots of effects. Unfortunately it’s late and I don’t have time to spend the next few weeks writing Haskell code to try your experiment. I’m guessing no-one else reading this does either. Perhaps you could instead direct us all to some existing projects that demonstrate the advantages you’re describing, so we could see the kind of code you’re thinking of and make up our own minds?