The whole presentation of monads as contexts (containers that store values) is very deceptive in my opinion. Especially when following Functor and Applicative.

The whole presentation of monads as contexts (containers that store values) is very deceptive in my opinion. Especially when following Functor and Applicative. This creates an illusion that Monad is about modifying values just like Functor/Applicative, while, in fact, it's mostly about modifying the context. I had a great success understanding Monad as a sequential program. The simplest way to write such a program would be just to chain elementary statements with the >> operator, however, to do any kind of control this way you'd need to rely on implicit state (think of programming in Assembler where you do branches based on implicit flag registers set by the previous instructions and the branch target itself is implicitly a new program). So Monad is just the minimal improvement over this that allows control structures without need of implicit conventions. It achieves this with three simple additions to the basic sequential model: 1. add explicit results to the statements 2. allow a switch after each statement based on its results 3. add pure elementary statements (that don't do anything other than returning the value they have been created with) so we could transform results without modifying the context. You can still do the simple chaining of statements in the Monad but whenever you need conditional/switch - you can do it explicitly with the >>= operator, whose argument is essentially a switch table, that assigns a new sequence of statements for each value. You still need to figure out how do the List monad takes multiple branches in its switches simultaneously but it might be easier for a programmer to understand than container-value analogy.