4 ms·

Accusing Haskell of being "less advanced" because it actually exposes Monads to you and permits you to use them is very much like accusing C++ of lacking power

Accusing Haskell of being "less advanced" because it actually exposes Monads to you and permits you to use them is very much like accusing C++ of lacking power vs. C because it permits you to overload the square brackets. I addressed this a bit in a response to jrockway (http://news.ycombinator.com/item?id=1170325 http://news.ycombinator.com/item?id=1170325), but wanted to make it clear here: my complain is not that monads are exposed, sugared up, and/or "allowed", because I think that's great - to the extent that we are "stuck in the IO Monad" in other languages, I agree, that is not a good thing. My problem is that (to some extent, at least) dealing directly with the pattern is necessary if we want to handle stateful computations, and it's less convenient than simply writing the computation naturally, with state. My accusation (and I know it's not a new one by any means) is merely that Haskell artificially limits its expressive ability and that state monads are a workaround, not that all monad usages are a problem (or even a symptom).

jerf 17y ago
You may know these things, but to be clear: Nothing in Haskell stops you from using the usual functional mechanisms for passing state as explicit parameters to functions. The State monad is not necessary. In fact you can pretty much ignore the fact it exists if you want from what I can see. It's just useful because it's simpler than passing the state of the computation around. You say that in Haskell it's harder, so I conclude you must not be talking about "the state of a computation" the way I am, but just talking about state in general, including the stuff you'd have to access through IO. I still fail to see how this is harder than in any other functional langauge, excepting that there's no convenient "final global fallback". Haskell isn't quite unique in that (Erlang arguably falls here too), but it is very unusual. My perspective may be skewed by my fairly extensive work in Erlang, I've learned how to deal with this issue. But other than the lack of a true global state I'm not sure what you could be thinking of that's really any harder. Incidentally, while I use and enjoy Haskell, I'm not besmitten with it. I'm truly interested in what you see as a problem, but I'm having trouble matching your accusations to my experiences.

jerf 17y ago

You may know these things, but to be clear: Nothing in Haskell stops you from using the usual functional mechanisms for passing state as explicit parameters to functions. The State monad is not necessary. In fact you can pretty much ignore the fact it exists if you want from what I can see. It's just useful because it's simpler than passing the state of the computation around. You say that in Haskell it's harder, so I conclude you must not be talking about "the state of a computation" the way I am, but just talking about state in general, including the stuff you'd have to access through IO. I still fail to see how this is harder than in any other functional langauge, excepting that there's no convenient "final global fallback". Haskell isn't quite unique in that (Erlang arguably falls here too), but it is very unusual. My perspective may be skewed by my fairly extensive work in Erlang, I've learned how to deal with this issue. But other than the lack of a true global state I'm not sure what you could be thinking of that's really any harder. Incidentally, while I use and enjoy Haskell, I'm not besmitten with it. I'm truly interested in what you see as a problem, but I'm having trouble matching your accusations to my experiences.