4 ms·

I think the real reason Monads haven't been widely adopted is that there isn't a compelling need for them. Laziness, purity and referential transparency are nic

I think the real reason Monads haven't been widely adopted is that there isn't a compelling need for them. Laziness, purity and referential transparency are nice-to-haves in most languages, whereas in Haskell, they're need-to-haves. Computers are imperative by nature. They have state. That Haskell has the capability to shield us from that is really, really cool, but that doesn't mean it's necessary to write good software.

oconnor0 14y ago
Except that Monads are compositional (and have reasoning properties) that "normal stateful programming" doesn't allow for.
chii 14y ago
electricity and other modern day conveniences are also not necessary to stay alive, but it sure makes it a lot more comfortable.
- lmm 14y ago
  Do you have an example of something that can be more comfortably expressed with a monad, even in a language with imperative constructs? To me monads have always seemed like a crutch for a deficient language. (A lisp advocate once told me tail recursion was great because it let you write an event loop without getting a stack overflow. The example code they gave would have been much clearer as a "while" loop, but I guess lisp doesn't have those. It seems like the same thing to me)
  - olavk 14y ago
    A better reason: Tail recursion lets you implement "while" if you miss it.
    - lmm 14y ago
      That explains why I want tail recursion in lisp, a language that doesn't have "while". But it doesn't explain why I would ever want or need tail recursion in python, which already has while. In the same way, I can see why I want monads in Haskell. But why would I ever want or need monads in a language that has first-class imperative constructs?
      - olavk 14y ago
        Agreed about tail recursion in Python, promoting recursion as an alternative to loops is contrary to the sprit of Python and "one obvious way to do it". Monads vs imperative languages is a bit different though, since Haskell-style monads are more than just a way of allowing an imperative style. For example many other features like list comprehensions and parsing is also based on monads in Haskell. However the real value of Haskell-style monads is that it is clear when you don't use them. So it is explicit in the type system which functions have side effects and which don't.
        lmm 14y ago
        >Monads vs imperative languages is a bit different though, since Haskell-style monads are more than just a way of allowing an imperative style. For example many other features like list comprehensions and parsing is also based on monads in Haskell. So maybe monads are useful for implementing language internals. But if we assume my language has list comprehensions and a parser (however they're implemented internally), what would I as a user of the language want monads for? I keep hearing that monads are great, but every code example I've seen using them seems like something that I could do more easily in python, without a monad. So I'd really like to see any examples of code that you would want to write using monads, even in a language that has imperative constructs.
        talaketu 14y ago
        Check some of the pyparsing examples.
  - jerf 14y ago
    "Do you have an example of something that can be more comfortably expressed with a monad, even in a language with imperative constructs?" STM. And it may not be immediately obvious that it does need to be a monad, if you don't deeply understand how it is being used. There's more to it than meets the eye at first.
    - gliese1337 14y ago
      "STM" to me means "Scanning Tunneling Microscope", so I was a bit confused until I googled and realized "Ah! Software Transactional Memory!" And you're right, it's not immediately obvious that it needs to be a monad. Could you elaborate?
      - Locke1689 14y ago
        http://research.microsoft.com/en-us/um/people/simonpj/papers/stm/beautiful.pdf http://research.microsoft.com/en-us/um/people/simonpj/papers...
      - jerf 14y ago
        I'm going to run on the theory you don't know Haskell. In this case, it's like someone who doesn't know OO at all asking why on Earth they'd want the Factory pattern. It isn't that I can't explain it per se, but no satisfying answer can be fit into an HN post. So I didn't try. To forestall the "copout" accusation: Basically, being a monadic value means you get the full range of monadic programming constructs available to you while still being isolated by the type system, so you get isolation while still being able to do real work, and the STM system takes extensive advantage of the fact that the do syntax actually desugars into a long series of closures, which means it can do things like retry and choice and stuff in a natural, safe way. But I am well aware that doesn't sound very impressive in isolation, because there's still a great deal of important nuance lost in that description, in much the same way that a similarly-detailed description of the factory pattern sounds generally unimpressive. ("What, it lets me either construct one thing or the other? Big whoop, here's how I do it in my procedural language, basically by just doing it. What's the big deal? Why does it make such a big fuss over something so simple?" Which is a good question, if asked honestly, but a terrible argument, which is how it would usually be meant.)
talaketu 14y ago
Computation is imperative by nature?
- chao- 14y ago
  Well, he said "computers" not "computation", but I can see how stating the former necessarily begets the latter. I want to back him up in some ways, but to also narrow the scope of his statement to not include all computers: The presence of a separate, non-computational storage in computers based on the von Neumann architecture implies the representation of state (at some level or another) is possible by those same machines. Consequently, we are tempted to utilize that capacity for state as storage for intermediate data within program execution itself, rather than just as a place to store the executed program itself. I could be totally missing the mark on it having to do with the von Neumann model of storing, fetching and executing programs. But from my limited reading about computers such as ENIAC, which required the circuit to be altered to route signals prior to execution, and then run through the program all at once. Someone please correct me if I'm wrong, because this stuff fascinates me and I'd love to be told straight. TL;DR: Storage implies state, so we wrote tools (languages) to leverage that.
  - talaketu 14y ago
    Yes absolutely the von Neumann architecture gave rise to the dominant means of computation - formulas and algorithms translated into imperative programs yoked to instruction pointers and addressable memory. But there is that step of translation. Perhaps we became so fluent that we stopped noticing we were doing it, and perhaps even to start thinking imperatively. But it's not "natural". Look at computing polynomials by differences (giving rise to the idea of the difference engine): better described as an iterated procedure than an imperative program. Or "constuctive": Construct an ellipse naturally by the pins and string method. Bisect an angle naturally using straight-edge and compass.
Rickasaurus 14y ago
Isn't it though? Good is certainly a relative term. Programming is a young endeavour, and advancements will be made in languages for a long time to come. We should continually reevaluate our tools so that we can make the best software we can.
Locke1689 14y ago
Monads have already been adapted into C# via LINQ. That's as mainstream as it gets. Your premise is false.
- olavk 14y ago
  I think this is somewhat misleading. If I understand correctly, only the SelectMany method in Linq is monadic. This is only a minor part of Linq, and not at all comparable to how monads are used in Haskell.
batterseapower 14y ago
Monads are to state as fruits are to apples: one of their applications (and probably the most common one) is for state, but it's by no means the only application.

oconnor0 14y ago

Except that Monads are compositional (and have reasoning properties) that "normal stateful programming" doesn't allow for.

chii 14y ago

electricity and other modern day conveniences are also not necessary to stay alive, but it sure makes it a lot more comfortable.

lmm 14y ago
Do you have an example of something that can be more comfortably expressed with a monad, even in a language with imperative constructs? To me monads have always seemed like a crutch for a deficient language. (A lisp advocate once told me tail recursion was great because it let you write an event loop without getting a stack overflow. The example code they gave would have been much clearer as a "while" loop, but I guess lisp doesn't have those. It seems like the same thing to me)
- olavk 14y ago
  A better reason: Tail recursion lets you implement "while" if you miss it.
  - lmm 14y ago
    That explains why I want tail recursion in lisp, a language that doesn't have "while". But it doesn't explain why I would ever want or need tail recursion in python, which already has while. In the same way, I can see why I want monads in Haskell. But why would I ever want or need monads in a language that has first-class imperative constructs?
    - olavk 14y ago
      Agreed about tail recursion in Python, promoting recursion as an alternative to loops is contrary to the sprit of Python and "one obvious way to do it". Monads vs imperative languages is a bit different though, since Haskell-style monads are more than just a way of allowing an imperative style. For example many other features like list comprehensions and parsing is also based on monads in Haskell. However the real value of Haskell-style monads is that it is clear when you don't use them. So it is explicit in the type system which functions have side effects and which don't.
      - lmm 14y ago
        >Monads vs imperative languages is a bit different though, since Haskell-style monads are more than just a way of allowing an imperative style. For example many other features like list comprehensions and parsing is also based on monads in Haskell. So maybe monads are useful for implementing language internals. But if we assume my language has list comprehensions and a parser (however they're implemented internally), what would I as a user of the language want monads for? I keep hearing that monads are great, but every code example I've seen using them seems like something that I could do more easily in python, without a monad. So I'd really like to see any examples of code that you would want to write using monads, even in a language that has imperative constructs.
        talaketu 14y ago
        Check some of the pyparsing examples.
- jerf 14y ago
  "Do you have an example of something that can be more comfortably expressed with a monad, even in a language with imperative constructs?" STM. And it may not be immediately obvious that it does need to be a monad, if you don't deeply understand how it is being used. There's more to it than meets the eye at first.
  - gliese1337 14y ago
    "STM" to me means "Scanning Tunneling Microscope", so I was a bit confused until I googled and realized "Ah! Software Transactional Memory!" And you're right, it's not immediately obvious that it needs to be a monad. Could you elaborate?
    - Locke1689 14y ago
      http://research.microsoft.com/en-us/um/people/simonpj/papers/stm/beautiful.pdf http://research.microsoft.com/en-us/um/people/simonpj/papers...
    - jerf 14y ago
      I'm going to run on the theory you don't know Haskell. In this case, it's like someone who doesn't know OO at all asking why on Earth they'd want the Factory pattern. It isn't that I can't explain it per se, but no satisfying answer can be fit into an HN post. So I didn't try. To forestall the "copout" accusation: Basically, being a monadic value means you get the full range of monadic programming constructs available to you while still being isolated by the type system, so you get isolation while still being able to do real work, and the STM system takes extensive advantage of the fact that the do syntax actually desugars into a long series of closures, which means it can do things like retry and choice and stuff in a natural, safe way. But I am well aware that doesn't sound very impressive in isolation, because there's still a great deal of important nuance lost in that description, in much the same way that a similarly-detailed description of the factory pattern sounds generally unimpressive. ("What, it lets me either construct one thing or the other? Big whoop, here's how I do it in my procedural language, basically by just doing it. What's the big deal? Why does it make such a big fuss over something so simple?" Which is a good question, if asked honestly, but a terrible argument, which is how it would usually be meant.)

talaketu 14y ago

Computation is imperative by nature?

chao- 14y ago
Well, he said "computers" not "computation", but I can see how stating the former necessarily begets the latter. I want to back him up in some ways, but to also narrow the scope of his statement to not include all computers: The presence of a separate, non-computational storage in computers based on the von Neumann architecture implies the representation of state (at some level or another) is possible by those same machines. Consequently, we are tempted to utilize that capacity for state as storage for intermediate data within program execution itself, rather than just as a place to store the executed program itself. I could be totally missing the mark on it having to do with the von Neumann model of storing, fetching and executing programs. But from my limited reading about computers such as ENIAC, which required the circuit to be altered to route signals prior to execution, and then run through the program all at once. Someone please correct me if I'm wrong, because this stuff fascinates me and I'd love to be told straight. TL;DR: Storage implies state, so we wrote tools (languages) to leverage that.
- talaketu 14y ago
  Yes absolutely the von Neumann architecture gave rise to the dominant means of computation - formulas and algorithms translated into imperative programs yoked to instruction pointers and addressable memory. But there is that step of translation. Perhaps we became so fluent that we stopped noticing we were doing it, and perhaps even to start thinking imperatively. But it's not "natural". Look at computing polynomials by differences (giving rise to the idea of the difference engine): better described as an iterated procedure than an imperative program. Or "constuctive": Construct an ellipse naturally by the pins and string method. Bisect an angle naturally using straight-edge and compass.

Rickasaurus 14y ago

Isn't it though? Good is certainly a relative term. Programming is a young endeavour, and advancements will be made in languages for a long time to come. We should continually reevaluate our tools so that we can make the best software we can.

Locke1689 14y ago

Monads have already been adapted into C# via LINQ. That's as mainstream as it gets. Your premise is false.

olavk 14y ago
I think this is somewhat misleading. If I understand correctly, only the SelectMany method in Linq is monadic. This is only a minor part of Linq, and not at all comparable to how monads are used in Haskell.

batterseapower 14y ago

Monads are to state as fruits are to apples: one of their applications (and probably the most common one) is for state, but it's by no means the only application.