4 ms·

I have been doing programming, including functional programming for more than two decades, I still don't really know what a "monad" is. Each time someone explai

by kuon 8y ago

I have been doing programming, including functional programming for more than two decades, I still don't really know what a "monad" is. Each time someone explains it to me, I understand something different.

Matthias247 8y ago
The way I accepted it after years of confusion, and without still understand the word: A monad is any type which supports 2 specific operations. One maps an type into it's monadic form, and the other allows to apply functions to monadic types and returns the monadic type again. The latter is sometimes called bind or flatmap. For Future types, the first thing could be called MakeReadyFuture(type), the second one Future.then(result => functionWhichReturnsANewFuture).
- pimeys 8y ago
  ... which allows a generic composition enabling imperative programming in a purely functional language. Haskell has do notation, that sugars the syntax to look like one is writing imperative code, even though it's all about composing Monads.
pas 8y ago
Monads are containers for which .map, and .flatMap (>>= in Haskell) make sense. Future, Option, List, State/IO, etc. And the do-notation that some comments mention become a long list of flatMap/filter/map invocations. do { futRecord <- getDBrecord(username, passw) uid = futRecord.map(record -> record.id) username = futRecord.map(record -> record.name) futResult <- setUserLastLoggedIn(uid, now()) futResult <- checkUserACL(uid, operation.roles) } yield username This is just an abstraction, and it's not exactly a pretty one, but better than the flatMap hell in functional languages. The do-notation uses the same monad throughout, in this example the Future one. The final yield is a map, the "<-" lines all represent a flatMap. Finally, Monads are very much like Vector Spaces in Maths. You have Axioms for both, and if the object satisfies them, it's a Monad or Vector Space! https://devth.com/2015/monad-laws-in-scala https://devth.com/2015/monad-laws-in-scala https://en.wikipedia.org/wiki/Vector_space#Definition https://en.wikipedia.org/wiki/Vector_space#Definition
- forkerenok 8y ago
  I would remove "containers" from the first line. In my reading it is ANYTHING for which monad laws hold.
  - Sharlin 8y ago
    For better or worse, "container" is the most intuitive concept to use when trying to explain monads. Yes, there are monad instances that don't really fit the container model, but they're not important at first. Definining "monad" as a thing for which monad laws hold is exactly the sort of almost-tautological non-explanation that makes people roll their eyes at FP aficionados. However, I agree that the important step in understanding monads as an abstraction is realizing how map and flatmap make sense for many things other than lists.
    - pas 8y ago
      I guess flatMap is very misleading to newcommers. Probably simply calling it chaining, composition, or even "then" would help.
      - Sharlin 8y ago
        That's true, although it's better than "bind".
      - sullyj3 8y ago
        I like chaining, that's a good analogy. I feel like, now that I have a certain level of intuitive understanding of what bind does, to me, the `>>=` symbol best represents what the operation does. It just looks like some kind of physical gadget that extracts a thing from a container, does something to it, and injects it into the next container. This is pretty ironic given Haskell's (somewhat deserved) reputation as impenetrable symbol soup. I don't know whether I'd endorse trying to use an intuitive mnemonic like this to explain monads to FP beginners.
        8y ago
haberman 8y ago
Several people found my blog entry on this enlightening: http://blog.reverberate.org/2015/08/monads-demystified.html http://blog.reverberate.org/2015/08/monads-demystified.html
Tyr42 8y ago
Just to add more different explanations, since that'll help. http://blog.sigfpe.com/2006/08/you-could-have-invented-monads-and.html http://blog.sigfpe.com/2006/08/you-could-have-invented-monad... This one is my favourite, and does it well by example and walking through three different cases, then generalizing.

by kuon 8y ago

Matthias247 8y ago

The way I accepted it after years of confusion, and without still understand the word: A monad is any type which supports 2 specific operations. One maps an type into it's monadic form, and the other allows to apply functions to monadic types and returns the monadic type again. The latter is sometimes called bind or flatmap. For Future types, the first thing could be called MakeReadyFuture(type), the second one Future.then(result => functionWhichReturnsANewFuture).

pimeys 8y ago
... which allows a generic composition enabling imperative programming in a purely functional language. Haskell has do notation, that sugars the syntax to look like one is writing imperative code, even though it's all about composing Monads.

pas 8y ago

Monads are containers for which .map, and .flatMap (>>= in Haskell) make sense. Future, Option, List, State/IO, etc. And the do-notation that some comments mention become a long list of flatMap/filter/map invocations. do { futRecord <- getDBrecord(username, passw) uid = futRecord.map(record -> record.id) username = futRecord.map(record -> record.name) futResult <- setUserLastLoggedIn(uid, now()) futResult <- checkUserACL(uid, operation.roles) } yield username This is just an abstraction, and it's not exactly a pretty one, but better than the flatMap hell in functional languages. The do-notation uses the same monad throughout, in this example the Future one. The final yield is a map, the "<-" lines all represent a flatMap. Finally, Monads are very much like Vector Spaces in Maths. You have Axioms for both, and if the object satisfies them, it's a Monad or Vector Space! https://devth.com/2015/monad-laws-in-scala https://devth.com/2015/monad-laws-in-scala https://en.wikipedia.org/wiki/Vector_space#Definition https://en.wikipedia.org/wiki/Vector_space#Definition

forkerenok 8y ago
I would remove "containers" from the first line. In my reading it is ANYTHING for which monad laws hold.
- Sharlin 8y ago
  For better or worse, "container" is the most intuitive concept to use when trying to explain monads. Yes, there are monad instances that don't really fit the container model, but they're not important at first. Definining "monad" as a thing for which monad laws hold is exactly the sort of almost-tautological non-explanation that makes people roll their eyes at FP aficionados. However, I agree that the important step in understanding monads as an abstraction is realizing how map and flatmap make sense for many things other than lists.
  - pas 8y ago
    I guess flatMap is very misleading to newcommers. Probably simply calling it chaining, composition, or even "then" would help.
    - Sharlin 8y ago
      That's true, although it's better than "bind".
    - sullyj3 8y ago
      I like chaining, that's a good analogy. I feel like, now that I have a certain level of intuitive understanding of what bind does, to me, the `>>=` symbol best represents what the operation does. It just looks like some kind of physical gadget that extracts a thing from a container, does something to it, and injects it into the next container. This is pretty ironic given Haskell's (somewhat deserved) reputation as impenetrable symbol soup. I don't know whether I'd endorse trying to use an intuitive mnemonic like this to explain monads to FP beginners.
      - 8y ago

haberman 8y ago

Several people found my blog entry on this enlightening: http://blog.reverberate.org/2015/08/monads-demystified.html http://blog.reverberate.org/2015/08/monads-demystified.html

Tyr42 8y ago

Just to add more different explanations, since that'll help. http://blog.sigfpe.com/2006/08/you-could-have-invented-monads-and.html http://blog.sigfpe.com/2006/08/you-could-have-invented-monad... This one is my favourite, and does it well by example and walking through three different cases, then generalizing.