But I was positively thrilled by some of the topics discussed and some of the discussions we got into on the day with the concurrency-track. Rich Hickey and the idioms he'd put into his Clojure-language really utilized some knowledge and nailed down some programming idioms for concurrency - in a much more useable manner - than what I've been used to seeing at academic conferences. Yes - it's hard; yes - threads and locks are a terribly bare-bones model to work with concurrency; yes - you really need to use immutable state. He essentially isolated four gradually more advanced forms of concurrency: An atom - essentially a cell, where you are given a synchronous read-and-set operation to work with it; a var - a persistent reference to a value that might change but is isolated inside a thread; a ref - a mutable storage location, which allows synchronous access, but only through transactions (segue to buzzword-compliant software transactional memory); and, agents which provide asynchronous access to mutable state. These idioms are available via fairly simple built-in keywords - inside a LISP-variant language (which is ok, but not reeeally to my liking, I'm more an ML/Haskell-kind-of-guy).
As Rich Hickey is not in academia - but develops programs for real customers, he needs to make these things actually work. He's chosen - wisely, I think - to target virtual machines. Building on top of custom Java libraries and compiling to bytecode running on the JVM, but also - via collaborators - aiming to target the CLR. This was so refreshing. He'd essentially made this language, because - as a consultant - he was extremely tired of developing concurrent programs in languages like Java, C++, and C#. How alien to an old fallen academic like myself. Actually having a problem before looking for a solution!
Ah - gotta run now. But in passing, I should mention also that I have - I promise myself this time (for the 5th time) - to go check out Erlang.
The guest from Erlang - Ulf Wiger - essentially shut up all the other participants on the Concurrency discussion panel, when he dryly remarked that Erlang-people had trouble comprehending concurrent programs running hundreds of threads; they were used to programs running hundreds of thousands of threads...
2 comments:
In all fairness, you can actually spawn millions of threads in Haskell. At least I've seen reports of users verifying this experimentally.
Ah. Hi Ulf! Thanks for dropping by.
Though you are, of course, right about Haskell, it was still a killer comment that did silence the rest of the panel. And that's something with both Rich Hickey and Simon Peyton-Jones present. ;-)
But - getting back to Haskell - for any other readers following: I see that there's even a fairly recent paper explaining about Haskell sparks, i.e. Haskell-style ligthweight threads. Thanks for pointing me in that direction.
Post a Comment