[kqr]

I think the problem is that people have learned the monad concept and then go overboard with it. Only monads are like async code with callbacks.

If people stuck to just explaining the IO monad specifically, which is a lot like async code with callbacks, then things would be better.

I wrote about this a few years ago: https://two-wrongs.com/the-what-are-monads-fallacy

[frogulis]

I like the analogy with musical instruments. Very practical.

I think you're right in saying that async is not representative of all monads, but it does help with questions that many beginners have, like "How do I get the value out of the maybe/IO/your-monad-here?"

[kqr]

I don't think it generalises that well, unfortunately. How to get the value out of Maybe is "just pattern match it". There's nothing process-like about it at all -- it's just a plain container/wrapper.

The async analogy works for some monads like ST and IO and whathaveyou but it's not generally useful, due to the wide variety of types that are monads.

[frogulis]

I think it's still a useful monad to look at. If you just pattern match Maybe, you're not really treating it like a monad or a functor, just as a tagged union that happens to implement a monad interface.

In contrast, there are easily understood reasons to use the monad interface of a promise/async. That's why I think it's a good monad for understanding the structure of monadic binding.

The way I see it is kinda like this, and I hope it makes some sense to others:

You can get the value out of a list... but there might be many or none. You can get the value out of a maybe... if it's there. You can even get the value out of the async function... but you'll just have to hold up what you're doing to wait for it.

This kind of (roughly) non-determinism is how I understand the concept of "effect", which is what Haskell frequently uses monads to model. A function returning a `M a` becomes "deterministic" (it always returns an `M a`) and benefits from the sort of equational reasoning that we like.

To be clear, the use of monads to represent effects is a software engineering decision and not inherent to monads.

It's definitely helped my understanding and I suspect it would help others too.