You may appreciate my own contribution, https://www.jerf.org/iri/post/2958/ , which includes an entire section titled "If They're So Wonderful Why Aren't They In My Favorite Language?", a section explaining why IO is not a good lens to understand monads and why "monads" don't really have anything to do with "making IO possible" (very common misconception), as well as what I believe to be one of the more practical applications of monads as a way of generating an audit log of how a particular value came to be what it is without. That example specifically arose from one of the rare instances I used the monad pattern in my own real code. Though I still didn't abstract out the monad interface, because if you only have one, that does you no good. The entire point of an interface is to have multiple implementations. It just happens to be a data type that could have implemented the monad interface, if there had been any use for such a thing in my code, which there wasn't.

I feel like the moment you understand what it is in Haskell you lose ability to explain it to people without heavy math theory background

But from what I observed its a group of fancy foreach loops that they put under same name for some reason

Here's my effort: https://m50d.github.io/2013/01/16/generic-contexts

From my experience having used Haskell (a long time ago), the main benefit of Monads is the `do` and <- syntax. Once you got your thing to satisfy the Monad interface, you unlocked the nice syntax for writing code. That, and compatibility with transformers.

Whether this is the best thing since sliced bread or not, is left as an exercise to the reader.

I think it's worth reading this if you want to understand the initial motivation for introducing Monads to Haskell: https://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/b...

(And in the context of the previous paper, this one motivates Applicative well I think: https://www.staff.city.ac.uk/~ross/papers/Applicative.pdf)

That said, I've never really understood the enthusiasm the industry has for introducing Monads outside of Haskell. As I understand it, at the time Philip Wadler wrote his paper, Haskell was pretty painful to use due to its adherence to purity. Monads were presented as a way to maintain purity while providing a principled way to support all kinds of effectful computations. But without some of the features Haskell provides (I'm thinking of typeclasses and HKTs in particular), and given that almost any language you'll be introduced to outside of Haskell already has ways to do e.g. IO or whatnot, it almost always ends up feeling like bolting something on with not a lot of benefit.

Don't get me wrong, I think there's value in stuff like https://github.com/fantasyland/fantasy-land --I find organizing how I think about computations around these algebraic concepts helps me a lot, personally. But that's distinct from introducing these concepts into day-to-day work in a non-Haskell language, especially on a team, which is often more trouble than it's worth unless everyone has already bought into it and is willing to deal with the meaningful friction introducing this stuff produces.

I assume the overabundance of Monad tutorials and libraries has to do with the cachet of knowing this relatively obscure, intellectual thing and being able to explain it to your peers, or to be more charitable, perhaps it's a byproduct of getting excited about learning this new, distinct way to approach computation and wanting to share it with everyone. But the end result is that now we have tons of ridiculous tutorials and useless Monad libraries in tons of languages.

A joke says that its because once you get it, you lose the ability to explain it like a normal person :)

And another joke says the best way to explain a monad tutorial is to write another one, so sorry for this.

Just think of it as a box.

If amazon sent items themselves, it would be hard to pack, no way to standardize, things would break often or fall out of their respective boxes.

Now, if you put it into one of the standardized boxes, that makes things 100x easier. Now you can put these on a conveyor belt, now you can have robots sorting these, now you can use tape to close them, standardization becomes easy as it's not "t-shirt,tennis ball,drill" but just "box box box".

So now you can do all kinds of things because it's all a box. And you can also stress test the box.

It's the same with these.

A. You can just have a function that: calls a something on IO, maps it's values, does a calculation, retries if wrong, stores the result, spits it out.

Or B. you can have functions that calls any function on IO, functions that map any value to any other value, functions that take any other function and if that function fails calls another function or retries, one that stores any value given to it and returns with information if it saved or not etc.

The result is the same in the end, but while 1 makes the workflow be strictly defined only for that case, and now you have to handle every turn and twist manually (did the save save? what if not? write a check, write a test that ensures its not and the check works, same if it does...) the 2 lets you define workflows with pre-tested, pre-built blocks that work with any part of your codebase.

And it makes your life 1000x easier because now you have common components that work with any data type inside your codebase, do things your way always, are 100% tested and make it easier to handle good cases, bad cases, wiring and logistics. And you can build pipelines out of them. Because at the end, what it does is just lets you chain functions that return wrapped values.

And you end up with code like:

val profileData = asAsync { network.userData(userId) } //returns a Async<Result<UserData, Error>

.withRetries(3) // Works on Async, and returns Result, retries async if fails

.withTraceId(userId) //wrapped flatmap that wraps success into Trace<T> and adds a traceId

.mapTrace(onError = { ErrorMappingProfile }, { user -> Profile(user.name, user.profileId) } // our mapTrace is a flatMap for Trace objects, so it knows how to extract trace objects, call the functions and wrap them again

.store("profile_data") //wrapped mapCatching again for storage explicitly that works on Trace objects, knows how to unwrap them, stores them,

.logInto(ourLogger) // maps trace objects into shared logger

Each of these things would before have to be manually written inside the function, the whole function tested for each edge case. if/else's, try/catch, match/when/switch.

This way, only thing you need to cover with tests now is `network.userData()`, as all other parts are already tested, written and do what they say they do. And you can reuse this everywhere in your projects. Instead of being a function you call with data, it becomes a function you give a box and it returns a box. Then you can give it to any other function that needs a box. If boxes make no sense, think of the little connectors on lego bricks, or pipe connectors in plumbing, or stacking USB adapters or power strips.

I can't stress enough how much this approach helped me in real life cases - refactoring old codebases especially, as once you establish some base primitives, the surface area starts massively collapsing as the test surface area increases.

Haskell is primarily a bunch of type gymnastics designed to give the impression of "purity" when no such thing exists in the world.