If you're designing a programming language, and you're planning to include monads solely for the sake of IO, the author has a point: Monads are a very complex way to perform IO, and you're better off with a simpler abstraction.

But monads are good for dozens of other things, including Bayesian inference[1], computation with optional values, list comprehensions, software transactional memory, quantum mechanics[2] and (to geek out a bit) anything that involves defining a lambda-calculus analog over a topos. Any time your problem domain includes a bunch of hairy matrix math, there may be a lovely, intuitive formulation using monads.

Now, if you're never programmed in Haskell, or if you've stuck to the IO monad, you may not understand why monads are a powerful way to tackle certain kinds of problems. But if you've never used monads in anger, how do you whether or not they're a useful tool?

If you want a relatively programmer-friendly language that supports monads, check out Scala's 'for' loop. It looks like a list comprehension, but it gives you about 90% of what you want from monads in practice.

[1] Here's an article I wrote on probabilistic programming with monads: http://www.randomhacks.net/articles/2007/02/22/bayes-rule-an...

[2] Here's a much cooler article on quantum mechanics with monads: http://blog.sigfpe.com/2007/03/monads-vector-spaces-and-quan...

There's an often-discussed (hypothetical) extension to Haskell's list comprehensions called Monad comprehensions. I suppose that would be similar to Scala's "'for' loop".

But really, the difference between 'do' notation and a syntax based on list comprehensions is not that big.

Compare:

[(x, y) | x <- [1 .. 10], y <- [1 .. 10]]

vs

do { x <- [1 .. 10]; y <- [1 .. 10]; return (x,y) }

The main difference is that it uses return (which is implicit in the comprehension syntax), and the final element in the do syntax is pushed into the first position in comprehension syntax.

(Another alternative would be liftA2 (,) [1 .. 10] [1 .. 10].)

This author seems to make several mistakes.

First believing that async calls to actors with side effects helps reasoning.

Second he conflates Haskells exposure of monads with the math of monads. Haskell just makes more explicit (and provable) what other systems indirectly model (often times muddling the ability to reason over it).

This post is full of spurious reasoning. Haskell's monads are mainly (ignoring the specifics of IO) syntactic sugar for a series of lambdas akin to a series of asynchronous functions linked via callbacks. While I get that this can be hard to grok given the magic of the syntax, it has nothing to do with the difficulty of monads in math.

do notation (in Haskell) is syntactic sugar, monads themselves are not.

As one who has dabbled with Haskell a bit here and there, "programmable semicolon" is the most apt metaphor I've seen.

Every time I have to break up a chain of method calls in Java with several lines of ternary null checks, I think about the Maybe monad.

I've found monads in programming languages to be a lot easier to understand than the myriad "guides" that explain them in obtuse ways.

Sometimes it really amazes me just how far out of touch with the mainstream people in the FP community can be. Any concept that the elite struggle with as much as monads simply has no place in the working programmer's toolbox. Haskell is a wonderful research language. It and its ilk will never be bread & butter.

The same could be said originally for generics and lambdas which have become increasingly common elements of programming. Complex ideas can yield powerfully simple and useful implementations.

I would say about one out fifty (2%) of bread and butter programmers can actually figure out how to pass an anonymous function as a parameter to another function. Granted, those 2% are probably a lot more important than the other 48%, but I don't think lambdas are actually common...

Also, if one of those 2% have to write code understood by the other 48%, they probably shouldn't use a ton of anonymous functions (or generics, whatever they are).

Really, so what should you use a ton of in hopes of making code easy to understand for a programmer that doesn't understand first-class functions? What makes you think they understand polymorphism? What about exceptions? Do you think they understand pass-by-value versus pass-by-reference? Do you think they understand any data structures? Pointers? Loops? Boolean logic?

It's ridiculous to complicate your code in an attempt to hit some moving target of "an ignorant person might be able to understand this." If a "bread-and-butter" programmer is using a modern language and doesn't understand functions, the correct response by everyone involved is for that programmer to spend some time understanding functions. I dare say the same is true for monads, although in many languages monads are hard to abstract out, and thus have less of an everyday value.

Are you saying that you think only 2% of programmers are capable of programming in Ruby? Blocks are pervasive in Ruby, and although technically slightly different than anonymous functions, conceptually very similar.

(Also, you mean "the other 98%".)

Perhaps the distinction between "can copy and paste existing syntax examples" and "understand what the syntax does" is significant.

Only 2% can figure out how to use a lambda? I guess it all depends on your definition of "programmer".

Note you did not say "already know", but "can actually figure out". I don't want to know what kind of software is being written by someone who, if they tried, could not actually figure out how to pass a lambda.

I would like to point out ruby makes it very difficult not to pass around anonymous functions.

>2% have to write code understood by the other 48%

that would be the other 98% ;)

Lambdas and generics are essential to writing modern C# code - that language everyone seems to deride as dumbed down for your average programmer. jQuery likewise uses a lot of anonymous functions, and even front-end devs without heavy code experience manage to use this.

FP research has contributed many valuable ideas to the programming mainstream. However, after watching entire rooms full of top 5% programmers scratching their heads in bafflement over explanations of monads I very much doubt monads will earn this distinction, at least not in any kind of explicit use.

Plenty of "the elite" find monads quite common place and use them effectively for real mainstream programming every day.

I might say people in the FP world are much more in touch with the future of programming then most. Languages like Haskell are solving problems (elegantly) that many mainstream programmers have not yet come across but they will.