Monads Are Not Metaphors

I've recently finished reading Learn You A Haskell For Great Good!, and I think the author's approach to monads works well. I'd read various metaphorical explanations that only served to further cloud the issue, but thanks to LYAH I finally got it.<p>In short, he has you using monads long before you understand them (Maybe and IO in particular), then slowly introduces monads by first explaining functors and applicative functors.<p>In retrospect, the mystique seems crazy. Monads are just not that confusing: they're simply values with added context, along with functions that let you interact with those values without losing the context. It's a shame that this powerful idea is so obscured by its supposed difficulty.

&#62; Here’s the deal: Haskell doesn’t allow side-effects. At all.<p>I disagree with this, and it was Eric Meijer's "Fundamentalist Functional Programming" lecture that really changed my mind. The point isn't that Haskell prevents side effects. It's that it requires you to be explicit about them. Indeed, some advocates say that Haskell is "the best imperative langauge". I don't know that I would go that far though.

I have to say, I had no idea what monads were before reading that article, and after reading it, I still don't.<p>It sounds like something to get the benefits of object-oriented programming while using functional programming, but I'm really confused.

When learning any new sufficiently abstract typeclass (whether it is Monad, Applicative, Functor, Monoid, Arrow, or whatever), the best way to learn it is in two phases: 1) What is the mathematical meaning of the typeclass? 2) How can the typeclass be applied (what are the instances) and how do they map to reality?<p>It is very tempting to try to jump quickly to 2 - but it helps to force yourself to avoid thinking about applications for a bit and understand the applications.<p>I think the article does achieve this.

I'd love to have the data to graph the ratio public_monad_tutorials/haskell_programmers over time.

A monad is like a tiger in a cage. You don't want it running around mauling all your code, so you transport it in cage. If someone needs your tiger for something they need to have the key to his cage. Also it is polite to put the tiger back in the cage if anyone else needs him.

I wish I knew Scala, I was too caught up trying to decipher the code to take in the author's point. I have a basic knowledge of monads but unfortunately wasn't able to glean anything further from this article.

I'm trying to parse all of this, but my understanding of Scala is shaky. Could anyone explain this statement -- I think it'd help a lot:<p><pre><code> sealed trait Option[+A] { def bind[B](f: A =&#62; Option[B]): Option[B] </code></pre> (My best guess: define a trait named `Option` ... something about an object of type A ... really not sure of the +. Then define a function `bind` that ... something about type `B` ... which takes an argument of type `f`? and returns the argument wrapped in an Option?)

It's ok that it takes some time for the idea of the necessity of Monads to spread. I bet it took at least the same time for the Haskell guys to understand the necessity of IO. ;-P

Great article. One of the more lucid explanations of Monads... although I do wish a different language was used. As much as people don't like C++, it is probably the simplest language to explain simple OO concepts (at least of the set which are expressible in C++).

I always liked MenTaLguY's explanation:<p><a href="http://bit.ly/fh1F2l" rel="nofollow">http://bit.ly/fh1F2l</a>

Historical correction: the monad idea originated with Eugenio Moggi not Philip Wadler.

A monad is not a metaphor, but a monad is like a simile.