Yes, I didn't include the papers below in my parent response because, “just read these dense academic papers to understand what monads are and why Haskell has them” doesn't tend to be good advice for Haskell beginners. But learning why monads came to be included in Haskell is useful if you want to dive deeper into this stuff:

Philip Wadler's original paper on Comprehending Monads [PDF]: https://ncatlab.org/nlab/files/WadlerMonads.pdf

Philip Wadler and Simon Peyton-Jones' paper on Imperative Functional Programming [PDF]: https://www.microsoft.com/en-us/research/wp-content/uploads/...

Simon Peyton-Jones mentions both papers and talks about why monads came to be part of Haskell in his talk on the history of Haskell here, with examples that are a little more accessible than the above papers: https://www.youtube.com/watch?v=re96UgMk6GQ [introduction to purity and then monads starts around 30:07]

It's a funny talk and it's worth watching in full, but here's a nice soundbite:

“So what did we do for IO? Well, we just didn't have any. [audience laughs] So the joy of being an academic, right, is you can design a language — in 1990, I beg to inform you — that had no input/output. A Haskell program was simply a function from string to string. That was what it was. … But this was a bit embarrassing…”

He goes on to talk about other ideas they explored to create effects, why they settled on monads, and why he wishes now they had called them something like “workflows” (as F# later did[1]) to make them sound less intimidating.

(Simon and Philip will both be at Haskell Exchange 2019 in London this coming week if anyone else, like me, enjoys spending two days as the dumbest person in the room: https://skillsmatter.com/conferences/11741-haskell-exchange-... )

[1]: https://blogs.msdn.microsoft.com/doriancorompt/2012/05/25/7-...

> Monads solve problems that are only made apparent by other design decisions in Haskell. In a non-functional, loosely typed context they are not so useful.

This is key. I've tried to write a "Monads in JavaScript" article many times over the years, but it's pointless, because you have to preface it with 100 imaginary constraints.

idk, rxjs, observables, and promises seem pretty popular. Doesn't mean it makes sense to try to write all your js code in an fp style though.

Sure they're popular, but the reason they don't talk about monads, even if they are monads in an abstract sense, is that in those problem domains the abstraction doesn't bring any clarity to the design.

Whether they talk about it or not, monads did inform their design. rxjs literally has methods named `flatmap`