<i>The performance implications of transactional memory. As programmers, we’re used to assignments being cheap.</i><p>For most business apps, "hundreds of cycles" is still dirt cheap. I should know. I've worked on Smalltalk apps with in-memory transactions. To my knowledge they work very well, and this is <i>not</i> an issue! Matters like this are swamped by generic issues involving network, DB, and disk access.<p>Another thing he's wrong about: there are frameworks in sufficiently powerful languages that don't necessarily require applications to be rewritten. (Example: properly implemented MVC apps in Smalltalk. Such frameworks could also be implemented in Lisp using macros.)<p>The reason why this stuff isn't more popular? Business apps could make good use of something like this, but the people who maintain these apps just aren't concerned about the issues STM solves. (Or they aren't aware that they really do have a stake in those issues.)
<i>So this is the true barrier to entry to STM: it requires a radical, deep, fundamental change in how people program, in order to work.</i><p>Writing massively-parallel code requires a radical, deep, fundamental change in how most people program. I don't think there's any getting around that. STM seems to work pretty well in Clojure, which uses mutable references to immutable values exactly as the author describes. It does require a different programming style from imperative languages, and doesn't pretend to have a way around that.