This is a somewhat misleading way to think about Haskell and monads—it puts the cart in front of the horse and obscures both how Haskell deals with effects and

This is a somewhat misleading way to think about Haskell and monads—it puts the cart in front of the horse and obscures both how Haskell deals with effects and how monads are more general and useful than just IO. This blog post ends up mystifying more rather than demystifying. Then again, this shouldn't be a surprise from an article that describes the Haskell ideas as "the Haskell monadic dogma"! You wouldn't expect a particularly charitable or educational account to start like that. A much better way to think about it is to think about IO without considering monads at all. One of Haskell's core characteristics is that it explicitly separates code with side effects from code without side effects using the IO type. This is a powerful design in and of itself—it's a tool for helping programmers manage effects and not a hack around laziness. Personally, more tools to manage effects is exactly what I want. After all, even in languages, code I write is carefully organized to separate most side-effects (API calls, database accesses... etc) from the domain logic, but this happens solely through convention and code organization. Having tools in the language to express the same separation is powerful. Note how I never needed to talk about monads here—IO is the important concept. With this in mind the real question is not "why does Haskell need monads?" but "why are monads a useful abstraction?". This gets a bit long for an HN comment, but I wrote a blog post with my thoughts a few years back. It started like this: > I believe the notion that Haskell uses “monads” to enforce purity is rather misleading. It has certainly caused quite a bit of confusion! It’s very much like saying we use “rings to do arithmetic”. We don’t! We use numbers, which just happen to form a ring with arithmetic operations. The important idea is the number, not the ring. You can—and most people do—do arithmetic without understanding or even knowing about rings. Moreover, plenty of rings don’t have anything to do with arithmetic. > Similarly, in Haskell, we use types to deal with effects. In particular, we use IO and State and ST, all of which happen to form monads. But it is still better to say we use “the IO type” to do IO or that we use State for state than to say we use “monads” to do IO or state. You can read the rest here: http://jelv.is/blog/Haskell-Monads-and-Purity/ http://jelv.is/blog/Haskell-Monads-and-Purity/ This is by no means a definitive discussion of monads or anything like that; it's just a perspective I found useful for understand what Haskell gets by having a monad abstraction and why it's interesting.