4 ms·

" I just think that the necessary pervasiveness of the pattern indicates that the language is not as powerful as it could be (I raise an eyebrow when I see any

" I just think that the necessary pervasiveness of the pattern indicates that the language is not as powerful as it could be (I raise an eyebrow when I see any pattern used very often anywhere), whereas fanboys sometimes take it as evidence that the language is beautiful " Very interesting observation! Generally recurring patterns in one language "disappear" in more advanced languages (as Peter Norvig's slides point out), either by new syntax or changes to the runtime . How could Monads or (by extension type classes) disappear in a new language? Something to think about.

jerf 17y ago
Actually, the problem with Monads in other languages is that they do disappear behind the statement separator (semi-colon in many languages). In Haskell terms, you're stuck in the IO Monad and can never, ever get out of it. An analogy: C has the array-dereference operator []. But that pattern is locked into the language, you can't do _anything_ but dereference C arrays in exactly the way the operator does. C++, Python, C#, and a wide variety of other languages unlock the array dereferencer by permitting the operator to be overloaded, and thereby permitting things other than a straight-up C array deference, ranging from dereferencing into something that presents the interface an array does (like some sort of ordered tree) but is not literally laid out as a contiguous block of memory, to things that aren't arrays at all, like keying into hash tables. 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. If you put aside the question of whether it's a good thing to have the power (a separate debate in both cases), it's not a very sensible accusation to level against Haskell. The Monad pattern appears everywhere in every language whether you know it or not, Haskell merely exposes to the user something that is already there. Calling a monad a "programmable semicolon" is not necessarily the best way to understand them, but it has more truth to it than some of the other metaphors tossed about.
- plinkplonk 17y ago
  "Actually, the problem with Monads in other languages is that they do disappear behind the statement separator (semi-colon in many languages)... The Monad pattern appears everywhere in every language whether you know it or not, Haskell merely exposes to the user something that is already there. " Yes I agree (haskeller myself). The "disappearance" I meant was addressing the original point of view that the repetition of the pattern was a weakness in the language, something like Visitor pattern disppearing in Common LIsp. (an intriguing idea to play with and a valid point of view). Your interpretation of disappearance goes the other way - something like continuations being hidden in fortran and explcit in Scheme. "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. If you put aside the question of whether it's a good thing to have the power (a separate debate in both cases), it's not a very sensible accusation to level against Haskell." A better analogy would be an argument about exposing call/cc in scheme. Is call/cc good language design? There are arguments on both sides. Haskell does continuations differently than Scheme. Which is "better"? And come on, no one is really "accusing" Haskell of anything. I for one, like the language a lot. If you will, think of this as a speculation about a successor language. 15 years from now (say) there will be a better language than Haskell in the statically typed lazy functional languages space, which absorbs the key positives of Haskell, has a few new ideas, and possibly treats Monads differently (or does away with them altogether). Clean (the language) deals with IO with uniqueness types with nary a monad in sight. Is that design "better"? Worth thinking about.
  - copper 17y ago
    Your point is spot-on. > A better analogy would be an argument about exposing call/cc in scheme. Is call/cc good language design? There are arguments on both sides. Haskell does continuations differently than Scheme. Which is "better"? To clarify this, here's a couple of questions whose answers might amuse you. Is it possible to implement explicit continuations in terms of monads? Is it possible to implement monads in terms of explicit continuations? If it is possible to implement A in terms of B (and not vice versa), then B is more basic than A.
    - 17y ago
- ewjordan 17y ago
  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.
tel 17y ago
I don't know if that's fully true. One pattern used nearly ubiquitously and having relatively little fear of vanishing is the function. That example makes me either doubt the power of that quote or curious as to what in the hell could out abstract abstraction. (More concretely, works like the Typeclassopedia seem to get at the heart as to why I think Monads are a different beast than language patterns like Singleton.)
- ewjordan 17y ago
  I agree with you - some patterns, like functions (yes, we're really starting to stretch the word "pattern" here...), appear because they are symptoms of good design. Sometimes, maybe even most of the time, monads appear as symptoms of good design, as well. But sometimes they appear as workarounds for language limitations, and that's where we run into trouble. I feel like most pure languages in any paradigm run into this problem a lot, and it's why I vastly prefer mixed languages. I don't know that I fully agree with what plinkplonk says; I don't really think monads or type classes should disappear in "better" languages, because they are very powerful tools to have in the box. I'm just concerned that in Haskell, because those powerful tools are there and relatively painless to use, other tools that have many fine uses have been pulled out, and the language loses expressive ability as a result.

jerf 17y ago

Actually, the problem with Monads in other languages is that they do disappear behind the statement separator (semi-colon in many languages). In Haskell terms, you're stuck in the IO Monad and can never, ever get out of it. An analogy: C has the array-dereference operator []. But that pattern is locked into the language, you can't do _anything_ but dereference C arrays in exactly the way the operator does. C++, Python, C#, and a wide variety of other languages unlock the array dereferencer by permitting the operator to be overloaded, and thereby permitting things other than a straight-up C array deference, ranging from dereferencing into something that presents the interface an array does (like some sort of ordered tree) but is not literally laid out as a contiguous block of memory, to things that aren't arrays at all, like keying into hash tables. 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. If you put aside the question of whether it's a good thing to have the power (a separate debate in both cases), it's not a very sensible accusation to level against Haskell. The Monad pattern appears everywhere in every language whether you know it or not, Haskell merely exposes to the user something that is already there. Calling a monad a "programmable semicolon" is not necessarily the best way to understand them, but it has more truth to it than some of the other metaphors tossed about.

plinkplonk 17y ago
"Actually, the problem with Monads in other languages is that they do disappear behind the statement separator (semi-colon in many languages)... The Monad pattern appears everywhere in every language whether you know it or not, Haskell merely exposes to the user something that is already there. " Yes I agree (haskeller myself). The "disappearance" I meant was addressing the original point of view that the repetition of the pattern was a weakness in the language, something like Visitor pattern disppearing in Common LIsp. (an intriguing idea to play with and a valid point of view). Your interpretation of disappearance goes the other way - something like continuations being hidden in fortran and explcit in Scheme. "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. If you put aside the question of whether it's a good thing to have the power (a separate debate in both cases), it's not a very sensible accusation to level against Haskell." A better analogy would be an argument about exposing call/cc in scheme. Is call/cc good language design? There are arguments on both sides. Haskell does continuations differently than Scheme. Which is "better"? And come on, no one is really "accusing" Haskell of anything. I for one, like the language a lot. If you will, think of this as a speculation about a successor language. 15 years from now (say) there will be a better language than Haskell in the statically typed lazy functional languages space, which absorbs the key positives of Haskell, has a few new ideas, and possibly treats Monads differently (or does away with them altogether). Clean (the language) deals with IO with uniqueness types with nary a monad in sight. Is that design "better"? Worth thinking about.
- copper 17y ago
  Your point is spot-on. > A better analogy would be an argument about exposing call/cc in scheme. Is call/cc good language design? There are arguments on both sides. Haskell does continuations differently than Scheme. Which is "better"? To clarify this, here's a couple of questions whose answers might amuse you. Is it possible to implement explicit continuations in terms of monads? Is it possible to implement monads in terms of explicit continuations? If it is possible to implement A in terms of B (and not vice versa), then B is more basic than A.
  - 17y ago
ewjordan 17y ago
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.

tel 17y ago

I don't know if that's fully true. One pattern used nearly ubiquitously and having relatively little fear of vanishing is the function. That example makes me either doubt the power of that quote or curious as to what in the hell could out abstract abstraction. (More concretely, works like the Typeclassopedia seem to get at the heart as to why I think Monads are a different beast than language patterns like Singleton.)

ewjordan 17y ago
I agree with you - some patterns, like functions (yes, we're really starting to stretch the word "pattern" here...), appear because they are symptoms of good design. Sometimes, maybe even most of the time, monads appear as symptoms of good design, as well. But sometimes they appear as workarounds for language limitations, and that's where we run into trouble. I feel like most pure languages in any paradigm run into this problem a lot, and it's why I vastly prefer mixed languages. I don't know that I fully agree with what plinkplonk says; I don't really think monads or type classes should disappear in "better" languages, because they are very powerful tools to have in the box. I'm just concerned that in Haskell, because those powerful tools are there and relatively painless to use, other tools that have many fine uses have been pulled out, and the language loses expressive ability as a result.