No!<p>EDIT: As a side note, I hope my tone doesn't come across as too harsh. I feel a bit bad about writing this way, but it's just something I've been thinking about—and frustrated by—for a while. I have no problems whatsoever with the author of this piece. I just want to make sure that people really pick up on where it's off the mark, and I'm a bit frustrated—largely with myself—that there is no good explanation of functional programming and monads that avoids many of these problems.<p>That is <i>not</i> the way to think about monads. It's an unfortunate failure of education/PR that people hang on to this notion. The way monads are often presented, it's a very natural conclusion. But it's also entirely misleading.<p>Monads are not tied to functional programming. They are not tied to <i>pure</i> functional programming. They are <i>not</i> about introducing IO effects to otherwise pure programs.<p>There is <i>one</i> that does that. One type that's a monad and that manages effects in Haskell. IO. But that is the IO type. Other monads? Other code using monads? It often has <i>nothing</i> to do with adding effects to a pure language! (Unless you stretch the definition of "effect", which, to be fair, many people do.)<p>There are lots of other monads. Lots! You can think of most Linq code as using <i>some</i> monad—but never for effects. It's in C♯, after all. Practically Java, and about as far from pure as you can get. Promises, in JavaScript, form a hobbled monad, which could trivially be a completely reasonable and correct monad if the people writing the spec weren't violently opposed to it.<p>The Wikipedia description... was not bad. Even if the author found it confusing. It wasn't great either. Even that was too narrow.<p>I like to think of it like this: a monad gives us a new, custom, way to <i>compose</i> things. In the case of IO, it does, indeed, give us a way to compose effectful programs. In the case of List, it gives us a way to compose nondeterministic functions (ie backtracking). In the case of Maybe, it lets us compose functions that may fail (ie early termination). And so on.<p>And the final paragraphs showcase yet another unjustified belief: that pure functional programming is basically just imperative programming <i>but less</i>. That's something I really need to write about <i>at length</i>. Suffice to say, it's more enlightening to think of pure functional programming—especially like Haskell—as almost <i>orthogonal</i> to imperative programming, not as a subset.<p>But, again, this is not something clear from most Haskell learning materials or evangelism. It's just so easy to describe it as imperative programming without assignment or imperative programming without side effects or... I did the same thing myself when I started. But that turned out not to be a good description at all. If anything, it just serves to confuse as soon as you get to intermediate or advanced Haskell topics.<p>I completely understand why people take this tack. The best way to learn is by drawing connections and analogies to what you know. And Haskell learning materials don't exactly provide the contrast or elucidation you'd need to avoid many of these pitfalls. I'm not sure what the best approach to rectifying this is, so for now I'll just write a few blog posts about it and not much more...<p>If you're curious, I've tried my hand at explaining monads too. But what I wrote is way too long and too rough and too unedited and, for all three reasons, on Quora[1]. Still, might be worth a look.<p>[1]: <a href="http://www.quora.com/Functional-Programming/What-are-monads-and-why-are-they-useful/answer/Tikhon-Jelvis" rel="nofollow">http://www.quora.com/Functional-Programming/What-are-monads-...</a>