[kqr]

> Monads seem to have this strange aura around them that attracts certain kinds of personalities

Historical accident.

There was a time, not very long ago, when we didn't know applicative functors were a useful separate subset of monads. We thought full monads were needed for all the neat things that applicatives are sufficient for.

During this time, lots of ink was spilled over monads. Had we invented applicative functors a little earlier, they would probably have gotten more of the spotlight they deserve.

-----

I also think people underappreciate the humble semigroup/monoid. But this is not historical accident, it is just that it seems to simple to be useful. But it is useful to be able to write functions generic over concatenation!

[kccqzy]

Indeed it was not long ago that in the language there was no relationship at all between the Applicative class and the Monad class. And then one release Applicative was made the superclass of Monad. That's the reason why we have sequence and sequenceA, sequence_ and sequenceA_, liftM and fmap, ap and <*>, liftM2 and liftA2, return and pure, traverse and mapM etc. All these pairs of functions do the same thing but are duplicated for historical reasons.

This historical accident has, IMO, made the language harder to teach.

[mncharity]

> And then one release Applicative was made the superclass of Monad.

After months of mailing list discussion and committee meetings. This is my go-to example for why I'd like a language with a push-out lattice of theories (path-independent accumulation of types, operators, laws). This should ideally "just work", no committees needed. Coding with math-like tight locality.

> This historical accident has, IMO, made the language harder to teach.

As LLM refactoring continues to improve, perhaps instead of current "here's an alternate prelude which cleans up historical mess for teaching", we might get to "here's a global refactoring of cabal and open docs to ..."?