There’s another argument that this article doesn’t really address: people struggle with monads because they’re introduced to monads (the solution) before they’re introduced to the scenarios in which monads are useful (the problem).

For me, as for many others, there was a particular monad tutorial that finally made it all click. The tutorial in question succeeded where others had failed because it separated the explanation into several deliberately ordered steps:

Introduce a few example problems, along with a preliminary solution (no monads involved!) to each problem.

Point out the repetitive structural similarities between the given solutions.

Show how the structurally similar bits of each solution can be factored out into a single class.

By introducing the problems first, and then presenting the author’s thought process as they work through the solutions to these problems “in real time”, the tutorial in question helps clarify the why behind monads: why did we start using monads in the first place? The vast majority of monad tutorials make no attempt to answer this question.

Of course monad tutorials about the Monad class are written in Haskell, because it uses two language features not present in other popular languages. JavaScript, Ruby, Python don’t have a type system. C# and Java have generics, and Common Lisp has generic functions, but none of them have value polymorphism. The whole reason that Haskell is used to teach this concept is because it’s only a satisfying class in Haskell.

The monad tutorial that worked for me was written in Ruby. I don’t think that a monad tutorial has to be written in Haskell to be successful. It certainly helps that Haskell’s type system forces you to use either monads or hand-rolled “monad-like” solutions to certain kinds of problems, but I think it’s possible to write an effective tutorial in practically any language, as long as the why behind monads is made clear.

I more or less agree with you here, but I do think that just how crufty the syntax gets in a particular language can really impact whether monads end up being compelling as a solution to the problem. If you introduce the problem, and then introduce a solution that seems just about as verbose and tedious as the one it’s replacing, then it ends up not seeming so great. See, for example, “Why monads have not taken the Common Lisp world by storm”.

This is probably true for a lot of concepts. I first saw the notion of an optional/sum type in Scala, but I didn’t get the point until I was later introduced to languages with non-nullable types and optional types.

There’s another argument that this article doesn’t really address: people struggle with monads because they’re introduced to monads (the solution) before they’re introduced to the scenarios in which monads are useful (the problem).

For me, as for many others, there was a particular monad tutorial that finally made it all click. The tutorial in question succeeded where others had failed because it separated the explanation into several deliberately ordered steps:

By introducing the problems first, and then presenting the author’s thought process as they work through the solutions to these problems “in real time”, the tutorial in question helps clarify the

whybehind monads: why did we start using monads in the first place? The vast majority of monad tutorials make no attempt to answer this question.The monad tutorial that worked for me was written in Ruby. I don’t think that a monad tutorial has to be written in Haskell to be successful. It certainly helps that Haskell’s type system forces you to use either monads or hand-rolled “monad-like” solutions to certain kinds of problems, but I think it’s possible to write an effective tutorial in practically any language, as long as the

whybehind monads is made clear.I more or less agree with you here, but I do think that just how crufty the syntax gets in a particular language can really impact whether monads end up being compelling as a solution to the problem. If you introduce the problem, and then introduce a solution that seems just about as verbose and tedious as the one it’s replacing, then it ends up not seeming so great. See, for example, “Why monads have not taken the Common Lisp world by storm”.

This is probably true for a lot of concepts. I first saw the notion of an optional/sum type in Scala, but I didn’t get the point until I was later introduced to languages with non-nullable types and optional types.