"The problematic thing about Haskell is not understanding monads, it's that they are necessary! They [... are ...] what happens if you try to force something na

"The problematic thing about Haskell is not understanding monads, it's that they are necessary! They [... are ...] what happens if you try to force something naturally "unfunctional" into a functional straightjacket." Er, I'm going to have to disagree with that as strongly as it is possible to do so. Monads are an incredibly powerful abstraction, to the point where they'd be useful even in a side-effect-ful language; for instance, for expressing non-determinism, or exceptions, or continuations, or any number of other features that would bloat your language spec if they were built-in. In Haskell's case, one of those features is IO, yes; but they're also used to provide many other features, including all the ones I just mentioned. And every feature implemented via monad is restricted to only the parts of the code where you need it - your exceptions aren't going to sneak out of the module they're meant to be in because of a forgotten catch; you can parallelise non-IO code with impunity, knowing there are no surprise side-effects; etc etc. I'd be inclined to compare monads, in terms of utility, to the abstract notion of objects, or to LISP-style macros. "Use FP where it makes sense, don't use it where it doesn't." Okay: http://augustss.blogspot.co.uk/2007/08/programming-in-c-ummm-haskell-heres.html http://augustss.blogspot.co.uk/2007/08/programming-in-c-ummm... There. Reasonably clean imperative code where you want it, with Haskell's enforced purity stopping your side-effects leaking into parts of your code where you don't want them. If you'd started from an inherently imperative base language, that wouldn't be possible. And all thanks to monads. [edit: a discussion of monads in the imperative context of C#: http://mikehadlow.blogspot.co.uk/2011/01/monads-in-c1-introduction.html http://mikehadlow.blogspot.co.uk/2011/01/monads-in-c1-introd... ]