

The problem with STM: your languages still suck - alrex021
http://enfranchisedmind.com/blog/posts/the-problem-with-stm-your-languages-still-suck/

======
stcredzero
_The performance implications of transactional memory. As programmers, we’re
used to assignments being cheap._

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 _not_ an issue! Matters like this
are swamped by generic issues involving network, DB, and disk access.

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.)

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.)

------
Zak
_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._

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.

