Interdisciplinary Skills

We interrupt our regular programme briefly for this choice bit of news, courtesy of CNN International.



This just came onto my radar: "Crooning ex-prime minister Koizumi is 'Ultraman King'".

At JAOO

I'm at JAOO. Overall quite a positively surprising experience. Much less business-lingo and far more fairly advanced conceptual and abstract stuff than I had expected. I knew that keynotes by Simon Peyton-Jones (Haskell-father) and talks by Don Syme (the man behind F#) would be good.

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