>The problem is that it's often very difficult to refactor synchronous code to be event-based since it requires an inversion of control. An attempt at changing

>The problem is that it's often very difficult to refactor synchronous code to be event-based since it requires an inversion of control. An attempt at changing clear, intention-revealing synchronous code to work asynchronously frequently results in ugly, hard-to-follow callback hell. This is true. There's some merit to the argument that you should plan for your IO code to be asynchronous from the beginning and structure your program that way. Havoc Pennington had a nice post about that: http://log.ometer.com/2008-09.html http://log.ometer.com/2008-09.html "Using async APIs is not premature optimization, it's correct design." Some languages provide constructs that make it cleaner to write asynchronous code in a way that looks more natural. F# has an async monad for this purpose. I'm guessing it can be done in Haskell as well. Lisp\Clojure macros may also be able to handle it.