[0] https://news.ycombinator.com/user?id=coolsunglasses [1] http://haskellbook.com/

What you'll usually see people insist is to describe monads by their operations, rather than through metaphor. That is, a monad is a type parametrized by some other type, with the following two functions:

1) return :: a -> m a 2) (>>=) :: m a -> (a -> m b) -> m b

such that three laws hold:

a) return x >>= f == f x b) m >>= return == m c) (m >>= f) >>= g == m >>= (\x -> f x >>= g)

For monads in Haskell, this is the technically correct definition.

That said, most people will tell you the best way to understand monads is to look at a few basic monad instance implementations (Maybe, Either a) and program with them, slowly learning new instances.

That is, a monad is a type parametrized by some other type, with the following two functions:

    1) return :: a -> m a
    2) (>>=) :: m a -> (a -> m b) -> m b

    a) return x >>= f == f x
    b) m >>= return == m
    c) (m >>= f) >>= g == m >>= (\x -> f x >>= g)

> "just a monoid in the category of endofunctors"

In fact, even among people who DO know the category theory necessary to understand this expression it's considered a very obtuse and useless explanation. Especially in the context of Haskell.

As for good readable introductions, I consider Wadler's paper "Monads for Functional Programming" to actually be a pretty good introduction. Another good intro is "You Could Have Invented Monads! (And Maybe You Already Have.)" http://blog.sigfpe.com/2006/08/you-could-have-invented-monad...