I find promises and futures in other languages (python, JavaScript, rust) close enough to how monads work to gain a very productive working intuition for how they work.

But how would you e.g. explain the monad laws from this intuition? Promises in JavaScript are not monads and does not obey the monad laws.

You don’t need to explain the monad laws to a beginner. They don’t need to know what bind does. All they need to know is how to use do syntax, and enough of how it works to use IO, Maybe, State, and a few others.

After they’ve been working for a month or so, they’ll “get” monads on a gut level, and the details won’t be so confusing to them.

Yeah, learning by example and by doing is the best way to learn any programming concept. But using misleading and confusing analogies along the way will just make the learning process harder, not easier.

Explaining monads in terms of promises and futures will make a beginner associate them with asynchronous programming, which might make some sense for some monads. But now show such a beginner a simple list comprehension and explain it is also a monad, and I assure you they will be very confused! Explaining concatMap in terms of promises is a very convoluted way to explain something quite simple.

I see what you’re saying. I agree that abstract metaphors confuse people. But clearly, the way we are teaching monads right now isn’t very effective for most people.

Haskell comes from a population that loves to understand things from the ground up, and most people learn by doing.

So, what if, instead of an abstract burrito metaphor, we taught people 4 monads: List, Maybe, State, and IO. We explain how do syntax does “something different” for each of them, and how IO is very similar to promises, but the others aren’t. Then we let them play with those for a few weeks, submit some PRs, let the panic of not understanding subside, and then teach them the theory?

Think about how JavaScript developers learn promises. They don’t understand how they work under the hood at all when they first start using them. Then, when they need to go deeper and look under the hood, that theory is connected to their practice, and makes much more sense to them.

> So, what if, instead of an abstract burrito metaphor, we taught people 4 monads: List, Maybe, State, and IO. We explain how do syntax does “something different” for each of them, and how IO is very similar to promises, but the others aren’t.

Yes, I am on board with that.

Yes you do. `flatMap`ping an array in javascript is using a monad every bit as much as `join`ing a linked list in Haskell. `Promise`s would be monads were it not for the (inexplicable, terrible) decision to make it impossible to nest them. C#'s `IEnumerable<_>` is not quite a monad, but only because it doesn't have a preferred implementation. Pick one, and it's as monadic as `Maybe` or `Either`. And of course function types are always monads.

What these languages don't have and Haskell does is a way to talk about all monads, all at once. Instead of

    replicateM :: forall m a . Monad m => Int -> m a -> m [a]

you have to separately implement

    replicateArray: <T>(count: number, ts: T[]) => T[][]
    replicateFunction: <S, T>(count: number, f: (s: S) => T) => (s: S) => T[]
    replicatePromise: <T>(count: number, t: Promise<T>) => Promise<T[]>

and so on.

Are you suggesting that flatMap is used all the time in JavaScript?