Nobody insists "monoid in the category of endofunctors" is universally preferable. It's a joke. What you'll usually see people insist is to describe monads by

Nobody insists "monoid in the category of endofunctors" is universally preferable. It's a joke. 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.