A technique I've had a reasonable amount of success with when teaching formerly imperative programmers is focusing on the constraints that force something like

A technique I've had a reasonable amount of success with when teaching formerly imperative programmers is focusing on the constraints that force something like a monad to exist (the "you could have invented it yourself" teaching approach): 1. One of the main points of functional programming is that your computations are the results of pure functions -- enabling niceties like thread-safety, type-safety, .... 2. That view of the world is imperfect because some interactions (like responding to user input) require a _sequencing_ of events. 3. Imperative languages accomplish that task easily. They just write the events in the sequence they want them executed. With constraint (1) though, your only option for sequencing is function composition. Whatever interface you choose, it _has_ to use composition somehow. 4. Monads are one of many possible solutions, and they're the one we happen to have standardized on. They're convenient because you can wrap up all that compositional nonsense into something that feels a lot like the mutable objects you're used to when you actually apply them in your code. That explanation skips over a lot of details, but it helps people build the initial spark of intuition to attach all the rest of the ideas onto. The mechanics of a monad, their capabilities, the available syntax, ..., don't seem to be the main stumbling block in my experience.