This blogpost and a lot of comments in this thread (but absolutely not all) don’t seem to realize that monads are an abstraction over lots of different, but com

This blogpost and a lot of comments in this thread (but absolutely not all) don’t seem to realize that monads are an abstraction over lots of different, but common programming constructs. - Read-only values (e.g. environment variable, configuration) - Write-only functions (e.g. logging, compiler output) - State (read-write-values) - Sum-types (e.g. Optionals/Maybe, Either/result) - Inductive lists - Arrays/vectors - Contexts (e.g IO, file handlers, database cursors, etc) - Functions - Sequenced operations - Continuations - Parallelization - Concurrency - Interpreters - Compilers - Combinations of all of the above (plus more) - And whole programs - (and a whole lot more) All of these can be built as monads, since it’s an extremely general abstraction. But when you try to attach the specifics of any of these constructs to your explanation/view/understanding of monads you will inevitably run into issues/contradictions with other things that are also monads. At its core, monads are just an interface with two (or three) functions: - unit/pure/return, which puts a value into a monad - bind (or map and join) which combines a value in a monad with a function from that value into the same monad (Plus some algebraic laws about how these functions behave when combined.) However, the technical simplicity of this interface does not make it easy to understand how and why it’s a useful abstraction over so many programming constructs. IMHO, the best way to get a grasp of this, is to actually use and play around with a bunch of of these constructs via these monadic functions. (I am also thoroughly convinced that you can ignore Category Theory if you are only interested in monads as they are used in programming.)