Maybe Monads Might Not Matter

This post/rant would be more persuasive if one got the impression that the author knows more about what he's talking about. One crucial aspect of monads Bracha ignores is that monads have statically-checked types (at least in languages like Haskell) which label what side effects can or (more importantly) cannot happen when a function (and/or monadic action) executes. This prevents impurity (in e.g. the IO monad sense) from breaking out into pure code; pure code that used impure code would have to change its type or wouldn't compile. This is a huge, huge, huge, huge win. It means that you can't "break" purity; pure functions stay pure. In contrast, a function in Erlang (a dynamically-typed functional language which is actor-based) which sends a message cannot be assumed to be a pure function, even in the event that a particular sent message always evokes the exact same reply. This is not to diss Erlang, which is a terrific language in many other ways (nor is it an attempt to diss Newspeak either).

Note also that Scala (a statically-typed language) has an actors library but also AFAIK has some support for monads (Scala experts can elaborate here). If only one concept was necessary in Scala, why have two?

Another point is that monads are used for a great deal more than modeling imperative features in pure languages (though that is a major part of what monads are used for). What about modeling functions-that-can-fail via the Maybe monad, or nondeterministic computations via the list monad, or computations that can raise error conditions via error-handling monads, or...? the list goes on and on. Monads can make any of these kinds of functions much easier to write and to compose. When one programming concept finds so many disparate uses, it's just possible that it's worth looking at closely.

I realize that Bracha is not a fan of static typing (his views on typing i.e. pluggable types have never seemed especially workable to me, but whatever, it's his itch so he can go scratch it), and conversely he is a fan of introspection in ways that are difficult to put into a statically-typed functional language. So I understand why he isn't a Haskell fan, and I have no problem with him pursuing another research direction. But this post smacks of (a) sour grapes that Haskell gets more attention than Newspeak, and (b) lack of understanding as to what monads are all about. Perhaps if he would read some of the tutorials he refers to a little more closely than he has, he would get it.

That doesn't mean that understanding a particular monad, like the IO monad, is harder than learning imperative / object orientated programming ab initio.

Of course, being too different from the status quo can make a suboptimal solution stick around - the QWERTY vs Dvorak situation is a good example (although as someone who tried and failed to go from QWERTY to Dvorak, and also learned Haskell from a background of OO and imperative programming, I can say the former is much harder than the latter).

I don't know what you computer science folk are talking about, but a monad in philosophy in one sentence is: a simple object (meaning indivisible) that causally interacts with other objects by observing its environment.

It is contrasted to other (more standard) views of objects that act upon other objects to make them move. Monads can't operate on other objects, they can only operate on themselves.

For more information google "Leibniz"