Why are monads so slow?

Why are monads so slow?

Just to get a taste of this Haskell fad, I conjured up this little benchmark:
http://pastebin.com/qgxnGaj6
It increments an integer ten thousand times in three different monads and then in a pure function.
First of all I must say that monad transformers are a bitch. It was really confusing to figure out what to lift, what not to lift, and in what order to unwrap them.
Second: I expected monad transformers to be slow, but I had hoped that at least the monads in GHC were optimized by now. After all, every Haskell program is a monad, how can you not make sure they're as tight as possible?


benchmarking Foo:
mean: 54.06153 us,
benchmarking Bar:
mean: 59.34639 us
benchmarking Baz:
mean: 392.4655 us
benchmarking Pure:
mean: 5.737042 us

The results are very dissatisfying. Monads are not only ugly and hard to work with, but they're also slow. IO-monadic code is approx. 10 times slower than pure code. Adding a StateT doesn't make things much worse, but a RWST more and your code is 6 more times slower, for a total of 60x slowdown over non-monadic code! Haskell is simply pathetic.

>>23
Just whom do you think you're kidding here? Fortran uses OpenMP crap, Ada uses semaphores and Erlang doesn't have shared state.

I've actually whipped out a book on parallel Ada and finding proof that it is a piece of shit was a snap:

"""
When the task currently executing within the protected object completes the body of the protected procedure, it will leave the object and the read/write lock will become inactive. At that point one of the other tasks will start its desired operation and activate a lock. Which of those many delayed tasks is selected is not defined by the core language.
"""

"""
The two locks provide mutually exclusive read/write access and mutually exclusive read access to the data within the protected object. As tasks may be delayed by these locks, it is important to keep the code in the bodies of protected procedures and functions (the critical sections) as short as
possible. Locks do not provide any synchronization. It is possible, therefore, that a group of reader tasks executing protected functions can starve writer tasks wanting to execute protected procedures. One can imagine from Figure 4.2
the possibility of newly arriving reader tasks replacing departing reader tasks, delaying those tasks that need the read/write access provided by the protected procedures.
"""