You're using monads whenever you code in any imperative language. The "bind" pattern is simply so pervasive that you don't even recognize that it's there, but a

You're using monads whenever you code in any imperative language. The "bind" pattern is simply so pervasive that you don't even recognize that it's there, but any time you use information obtained through one side-effect as part of another side-effect, that's a monad. That trivial read-a-name-and-print-a-greeting program which frequently shows up on the first day of Intro to Programming? Yep, that's using a monad. The difference with functional programming is that you can choose not to use monads, and IO, and other powerful abstractions which are baked in so pervasively into other languages. This enables more powerful static analysis and code reuse, but it also means that you need to be aware of what you're giving up in the process, such as the ability to choose effects at runtime based on the results of prior effects. People who have been using monads throughout their entire programming career are thus suddenly faced with trying to understand what a monad actually is and what sets it apart from non-monadic code. This leads to people writing tutorials and papers and blog posts, which causes people to think it's some super-complex concept accessible only to genius mathematicians, which leads to more tutorials... The neat thing is, once you've begun to see the pattern, it turns out to be useful in other areas besides sequencing I/O effects; non-determinism, coroutines, generators, parsers, and so on. Most languages make sequencing I/O effects so easy you don't even notice it's happening, but other monadic patterns, lacking built-in syntax, are far more unwieldy. Haskell puts them all on the same footing via the Monad typeclass and do-notation.