kachayev

Nice question!

It "easy". Cause it takes less characters in your code: you don't need "type classes" of any form, you don't care about liftings etc. You can start from 2-3 lines of code and see immediate result.

But it's really not that "simple", cause without constant thinking about type of each expr it becomes very hard to trace long chains of monad operations very quickly. Plus types are great for verifying that you didn't break anything inside your "do" block (which is painful in dynamic env).

To answer the question when STM is hard to use, you can imaging any case of simulation. Few years ago I worked with engine for real-time brokers trading simulations: thousands of independent players accept different information streams and make deals. Each deal is several steps of negotiations with two-phase commit. Plus different monitoring tools, timers, generators and randomizers.. Whole system was written in Erlang, and you know... two-phase commit is really hard to implement in right way without potential deadlocks and other problems. But it's looks good and "natural" (as to say) in Actors language. I used to try to do something like this with STM and I quickly gave up with mess of unreadable code.

This example was given to describe map/reduce pattern, not advice to use it instead of sum:

    reduce(operator.add, map(len, ss))

Regarding to debug function and partial function application, - it depends. As for me

    debug = partial(log, "debug")