> So monads are from functional programming, right? Monads are from category theory, a branch of math. Category theory is the study of generic, simple pattern

> So monads are from functional programming, right? Monads are from category theory, a branch of math. Category theory is the study of generic, simple patterns that work in many different contexts. The insights from recognising those patterns and how they fit together helps to find common ground between different areas of math that initially seem distinct. It's like a kind of OOP and pattern language, but for math instead of programming. Some patterns got names like Monad and Monoid because they were seen to crop op often, and useful insights could be gleaned from recognising the same pattern in different contexts. Then someone doing functional programming (FP) realised that the Monad pattern from category theory could be used as a good generic structure in FP to encapsulate many different patterns that were already being used in FP another way. Things like IO, state, efficient arrays, controlled parallelism, even kernel-like scheduling and user interaction, were already being done in pure FP before the introduction of monads. And before Haskell, which itself is quite old (~32 years). So FP didn't need monads. You just threaded all your functions together "by hand", using things like continuation-passing style or accumulators. There are several ways to do it, and it was possible to write large and sophisticated program this way. One day, someone realised that much of this threading things together like IO, state, etc could be done in a generic pattern called Monad with a signature (like a generic or interface in OOP) equivalent to the rules of Monad in category theory from math. They also developed the idea of monad comprehension syntax, like a list comprehension but generalised to any monad. Haskell was fairly new then, but it already worked fine without monads. These new-fangled FP monads and associated syntax so excited people in the Haskell community that they added them to the language, and redid the standard library around the concept. (Like the way Python initially didn't have list comprehensions, or async, but after those were added to the core language people started to use them a lot.) Nowadays, monads are seen as a functional programming thing, but really there are many FP languages that don't use monads, and monads aren't just for FP. They aren't necessary, but they are a nice pattern that helps write clearer, longer programs that carry things like state and side effects in a pure-functional world. The reason there are so many different kinds of Monad in Haskell, not just IO, comes from the same reason they were identified in category theory: They name a basic pattern that occurs naturally in many different contexts where it's not initially obvious. Once named, you can combine them. Unfortunately this leads to some confusing tutorials in Haskell, because Monad is a generic (in the OOP sense) abstraction for many kinds of "threading things together", which covers a lot of things you may write that seem very different from each other.