I don't feel like adding to the "what is a monad" literature. However, there was a lively discussion on LtU recently regarding this after a posting about Joe Ar

I don't feel like adding to the "what is a monad" literature. However, there was a lively discussion on LtU recently regarding this after a posting about Joe Armstrong's Three Laws of Programming Language Design [1]. They were brought up because one of the rules was What is difficult to understand you have to explain to people over and over again. The difficult to understand stuff is a real bummer. You have to explain it over and over again until you’re sick, and some people never get it, you have to write hundred of mails and thousands of words explaining over and over again why this stuff means and why it so. For a language designer, or author, this is a pain in the bottom. More than one person brought up monads in relation to the above quotation. The comments there are fairly short and make an attempt to be both precise and motivated. This comment [2], along with its first reply is closest to addressing all three of your questions. The longer approach, which I personally found descriptive, is chapters 11-13 of Learn You a Haskell for Great Good! [3]. This is by no means the succinct description that you are looking for, but it does a good job at motivating monads by bringing about functors and applicative functors as solutions to a certain problem, and then showing how "moands...are just beefed up applicative functors, much like applicative functors are only beefed up functors." [1] http://lambda-the-ultimate.org/node/4754 http://lambda-the-ultimate.org/node/4754 [2] http://lambda-the-ultimate.org/node/4754#comment-75528 http://lambda-the-ultimate.org/node/4754#comment-75528 [3] http://learnyouahaskell.com/chapters http://learnyouahaskell.com/chapters