The way I accepted it after years of confusion, and without still understand the word: A monad is any type which supports 2 specific operations. One maps an type into it's monadic form, and the other allows to apply functions to monadic types and returns the monadic type again. The latter is sometimes called bind or flatmap.

For Future types, the first thing could be called MakeReadyFuture(type), the second one Future.then(result => functionWhichReturnsANewFuture).

... which allows a generic composition enabling imperative programming in a purely functional language. Haskell has do notation, that sugars the syntax to look like one is writing imperative code, even though it's all about composing Monads.

Monads are containers for which .map, and .flatMap (>>= in Haskell) make sense.

Future, Option, List, State/IO, etc.

And the do-notation that some comments mention become a long list of flatMap/filter/map invocations.

  do {
    futRecord <- getDBrecord(username, passw) 
    uid = futRecord.map(record -> record.id)
    username = futRecord.map(record -> record.name)
    futResult <- setUserLastLoggedIn(uid, now())
    futResult <- checkUserACL(uid, operation.roles)
  } yield username

This is just an abstraction, and it's not exactly a pretty one, but better than the flatMap hell in functional languages.

The do-notation uses the same monad throughout, in this example the Future one. The final yield is a map, the "<-" lines all represent a flatMap.

Finally, Monads are very much like Vector Spaces in Maths. You have Axioms for both, and if the object satisfies them, it's a Monad or Vector Space!

https://devth.com/2015/monad-laws-in-scala

https://en.wikipedia.org/wiki/Vector_space#Definition

I would remove "containers" from the first line. In my reading it is ANYTHING for which monad laws hold.

For better or worse, "container" is the most intuitive concept to use when trying to explain monads. Yes, there are monad instances that don't really fit the container model, but they're not important at first. Definining "monad" as a thing for which monad laws hold is exactly the sort of almost-tautological non-explanation that makes people roll their eyes at FP aficionados.

However, I agree that the important step in understanding monads as an abstraction is realizing how map and flatmap make sense for many things other than lists.

> Definining "monad" as a thing for which monad laws hold is exactly the sort of almost-tautological non-explanation that makes people roll their eyes at FP aficionados.

Thank-you for crystallizing and articulating a frustration I have often, as a beginner to intermediate Haskeller.

I guess flatMap is very misleading to newcommers. Probably simply calling it chaining, composition, or even "then" would help.

I like chaining, that's a good analogy.

I feel like, now that I have a certain level of intuitive understanding of what bind does, to me, the `>>=` symbol best represents what the operation does. It just looks like some kind of physical gadget that extracts a thing from a container, does something to it, and injects it into the next container. This is pretty ironic given Haskell's (somewhat deserved) reputation as impenetrable symbol soup. I don't know whether I'd endorse trying to use an intuitive mnemonic like this to explain monads to FP beginners.

I know a lot of symbols, but I still get irritated when I encounter a new one, and I can't search for it. (At least math got a nice list: https://en.wikipedia.org/wiki/List_of_mathematical_symbols )

For math it's kind of okay. Because there the point is to talk about that theory. You introduce definitions, and theorems, and use them in proofs. Or in calculations.

And even in math proofs usually come with a lot of explanation. (At least the better ones.)

In software engineering maintainability is important.

And, sure, we can just accept that Haskell is something that you can't learn by looking at real world Haskell code. After all, you can't really learn real world "research math" by looking at it.

But I think real world code, especially one that is looking for maintainers should not err on the side of indecipherability and inapproachability.

I continue to chastise Scalaz for its bad naming and documentation convention. (Haskell is ... well, it's irredeemable.)

And TypeScript is getting into this mess too. The documentation for new releases with new type system goodies (and I really mean it, I like powerful type systems, I just don't want to spend my life on understanding them, I'm happy to use them to get particular jobs done), but with barely enough documentation to let serious TS users with many years of experience understand it.

That's true, although it's better than "bind".

They have something in them (sometimes just a very fuzzy non-explicit state, maybe a seed for a RNG, but there's something there, otherwise it'd be just a value). Every monad is a [type] constructor, wrapping something.

Or could you show a counterexample please?

Several people found my blog entry on this enlightening: http://blog.reverberate.org/2015/08/monads-demystified.html

Just to add more different explanations, since that'll help.

http://blog.sigfpe.com/2006/08/you-could-have-invented-monad...

This one is my favourite, and does it well by example and walking through three different cases, then generalizing.