Feed on
Posts
Comments

I’m on a sleepy late train home from London to Birmingham (trying to avoid the snow and inevitable rail problems tomorrow). This woke me up:

Patrick Logan says STM “…would be the most tragic turn imaginable for programming in the 21st century.”

Very wrong. And it is scaring me how shiny this thingy looks in so many people’s eyes right now. I don’t think it will be so long before this shows up in Java and C#.

Blimey, that’s gonna cause a bit of a ruckus.

(Update: Yep - the comments have started)

Viewing 2 Comments

    • ^
    • v
    I think he's right that it could get abused, but he's wrong to say it is therefore a Bad Thing. Database programmers and designers try to avoid contention but the locking and transactional mechanisms are there because it is unavoidable. Not being a multi-core programmer I don't know how well this analogy stretches but it seems to me that code should be shared-nothing as far as possible but that transactional memory is a Good Thing to have for those occasions when shared state is inevitable.

    Probably a good thing that I don't write code anymore :-)
    • ^
    • v
    What nonsense. The most tragic turn would be if neither STM nor message-passing concurrency caught on, and we continued trying to build everything with locks.

    I don't see much from Logan in terms of real arguments, except the repeated assertion that we shouldn't share state. Of course minimising shared state is laudable, but you can never squeeze all of the air out of the balloon. If we accept that sharing state, is necessary albeit rare, then STM is exactly what we need to make it tractable.

    The interesting thing for me about this STM-vs-message-passing debate is that we can essentially build Erlang in Haskell (i.e. implement message passing on top of STM) but we can't build Haskell in Erlang (i.e. STM on top of message passing).
close Reblog this comment
blog comments powered by Disqus