[stormbrew]

Not gonna lie, I was hoping for something funnier when I clicked this, because I find the endless stream of terrible examples and explanations for what a monad is extremely funny. Maybe that makes me a terrible person, I'm not sure.

But I think this is a rare useful addition to the corpus on layman understanding of "what is a monad?" Because it goes to an effort to try to destructure the problem and attack it from the angle of "why is a monad useful?", the answer to which, to most people, amounts to "it probably isn't to you right now, but it might be someday."

What it really comes down to, though, is that a monad is a way for you to define a program that actually Does Useful Things (like ask questions and act on them and output answers and occasionally tell you you're doing it wrong). You can use a C++ compiler or a ruby interpreter for this, or you can write a program in Haskell that generates one. And if you do the latter, monads are the construct that you build them with.

From there you have to explain why there's a benefit to going the roundabout route to useful things, but no one's going to understand them until they understand that basic premise.

[mattgreenrocks]

Disclaimer: still reckoning with monads.

The explanation is better than most I've seen, but it also feels a bit too reductive. IO is probably the best way to start understanding monads (futures also helped), but this idea of decorating instructions means you can do things like implement your own exception handling mechanism if need be. Lingual features of this scope usually aren't given to users, excepting a Lisp.

The hard part for me is grappling with how abstract a monad is. To this end, it almost seems easier to observe the uses of them rather than trying to fit them in a box (for now). Every explanation I read on them now sheds a bit more light on them, so it's just a matter of time and persistence.

[groovy2shoes]

This is hands-down the best introduction to monads:

http://blog.sigfpe.com/2006/08/you-could-have-invented-monad...

It starts with some motivation, then gives some specific examples, then generalizes to monads. It gave me a TON of insight about monads when I was first starting out, and I'm genuinely surprised that it doesn't get mentioned every time the monad discussion comes up.

Monads are so difficult to approach because they're so abstract and general -- all the theory in the world won't help you understand how they're useful. Once you've got the basics, the only way to grok monads is to use them. The IO monad alone is a good start but it's not enough. Try using a bunch of them to get a feel for what they have in common. The Maybe and Error monads come in handy a lot.

While most tutorials introduce monads with return and bind, monads can also be characterized by fmap and join. I'd recommend learning about that as the next step towards monad enlightenment. It helped to give me more insight into what a monad is, conceptually speaking. It's not strictly necessary but I found it interesting and helpful.

As an aside, if you find yourself struggling with Applicative Functors, try playing around with Elm [1] (Signals are applicative functors, and the <~ and ~ operators are the same as Haskell's <$> and <*> operators). That's what did it for me :)

[1]: http://elm-lang.org/Elm.elm