Think of a monad as a spacesuite full of nuclear waste in the ocean next to a container of apples. now, you can't put oranges in the space suite or the nucelar waste falls in the ocean, but the apples are carried around anyway, and you just take what you need. (http://koweycode.blogspot.com/2007/01/think-of-monad.html)
That explanation is pretty good if you understand monads. Otherwise it is completely useless.
I must not understand monads. I thought I knew the basics of how to use them, and have used them in the little bit of Haskell I have written, but that makes no sense at all to me.
What are the apples and oranges supposed to represent? Why would anyone want to put oranges in the spacesuit? When "you just take what you need", who is the "you", and are they swimming around in the ocean? Is the ocean significant at all?
I might be wasting my time trying to understand this analogy. I'm not up to speed on terms Haskellers throw around such as fields, rings, category theory, etc. Haskellers are welcoming of newbies and eager to teach, but are on a vastly different level than the average developer causing some of us to feel we're not smart enough to wield Haskell. Unfortunately even some basic concepts are so abstract that trying to explain them in concrete terms often leads to gibberish such as dons' analogy there.
I realize dons probably wrote that for the monad-savvy crowd as kind of an inside joke, perhaps I'd do well to just move on.
The best way to understand monads is to stop reading monad tutorials and write some code. There is only one particular trick to learning monads: use the >>= operator rather than do notation until you understand the basics. Then read this explanation of do notation:
Actually, this is just a special case of a general rule: "The best way to understand {{programming_concept}} is to stop reading {{programming_concept}} tutorials and write some code."
I think your general rule is only for those who learn this way. I find that a lot of programmers learn this way but not all...so this general rule isn't universal ;)
My current understanding of monads is that they are just a formalisation and a generalisation of an execution (or composition) mechanism that is implicit in most languages.
For example, in a language like C, the active part of the program is a composition of statements that are "executed" one by one and in order. The IO monad in effect implements this strategy.
The big thing is that the monad abstraction allows for other composition strategies too. The Maybe monad for example could be compared to a language that keeps executing things one by one until one of the computations fails, which results in the entire computation yielding a null result.
The type system helps keep these different strategies separate from each other, so that eg. one can't execute in parallel operations that require sequential composition.
