The "Monad Tutorial Fallacy" (2009)

A couple of earlier appearances netted some discussion:

https://news.ycombinator.com/item?id=28690798

https://news.ycombinator.com/item?id=431702

When folks ask "What is a monad?", they usually don't want the technical meaning, they're wondering what they can do to see why they should care or take the time to learn/use them. Here's a summary[0] that's as good as any I've seen.

> Summary. We have seen that a monad is a type constructor, a function called return, and a combinator function called bind or >>= . These three elements work together to encapsulate a strategy for combining computations to produce more complex computations.

[0] https://wiki.haskell.org/All_About_Monads#Summary

Like models, all abstraction are False, but some are usefull. I never found Monad to be usefull : a abstraction shared by async/await and map/list comprehension is for me a bad abstraction, because as a developper I typically want to know if I'm dealing with the former or the later. And want to manually combine them, like with gather.

It always disappointed me how utterly unlike a burrito a monad turns out to be. No hint of beans, queso, or salad.

That reminds me, I should write a Monad tutorial.