Nat Torkington on O’Reilly Radar writes a bit about concurrency and how it’s rather buggered. I was sort of siddling up to this topic myself when writing about Dreaming in Code and my thoughts stemming from that. Everything we’re doing today in concurrency seems like a bolt on. It’s like (sorry Perl), object orientation in Perl 5. Or better yet, the TCP/IP stack hammered into the side of VM/CMS back in the days of BITNET. (Showing my age and history, yeah, I know). It mostly works – and if you do it right, it’s OK – but it sucks to get your head around it.
The whole game to date has been thinking about serialized programming. The whole Von Neuman critter set us up and we’ve been following that same pattern for decades. I think our attempts to break away from that model can be likened to a carpenter trying to plumb a house – he keeps trying to nail the pieces together, or hammer them into shape. We just don’t think right about it.
It is interesting that Nat’s writing is focused on languages and systems, but I think he’s missing something in that we’re learning some pretty damn good lessons from web services – even this whole Ajax/Web 2.0 bullshit. Clearly we’re all pretty much still infants in our approach, but at least we’ve mentally busted out of that flat gridspace when we start thinking about multiple systems working together. The problems we’re dealing with, and soliving, in web services and doing those Ajax interfaces is a macro scale issue of threading, memory, and communications. The languages emulating it in a system are the micro scale. I think we’ve got a lot to learn from the macro scale goodies we’re cluing into. It means doing things differently, making different assumptions, and changing the way we approach problems.
I don’t know Nat’s friend Bryan O’Sullivan, but I certainly agree with his quote about concurrency. Bang on – it IS the language that’ll fuck us up. We don’t have the right grammar and vocabularly yet to really talk about the things that matter – or at least we’ve so overloaded those words with in-line single-threaded executation concepts that we can’t bust our heads out of it. I don’t know a darn thing about Haskell. Maybe it’s the shiz. Maybe it helps solve some of these problems. I think some of the object oriented concepts that you’ll find in Smalltalk and Objective-C do too.
But fundamentally, I think this problem goes all the way down to the hardware. We’re just too darn used to everything being “clocked” together. There’s been the period research into not keeping everything in lock step – when we can cross that barrier down at the hardware level, we’ll be able to do the same at the software level. Or maybe it’s the other way around – learning to do software between multiple, mostly-disconnected and certainly unsynchronized systems may lead us to some real knowledge on how to do it in hardware.
Will the day come that when you buy a home “computing” system, you’re actually buying a network backplane of some impressive magnitude and a pile of memory and CPU pieces that all plug into that same backplane? Where the hell does disk IO go in this setup? Or a screen attach for output? Or a keyboard, mouse, touchpad… Lots of unanswered questions except that we’ve been fundamentally building computer systems pretty darn similiarly for ages. There’s still a central “main bus” in most desktops and laptops. We’ve actually got pretty limited IO capabilities in our systems, when it comes right down to it – we’ve just hidden that behind some fast ethernet, firewire, or usb 2.0 connections. I’m not even sure where it’s going – but I know it’ll be a curve ball on our otherwise nice, neat euclidian grid.
You know who I’d love to be able to talk with this about? Grace Hopper. She was early enough in the game that I think she’d perhaps be able to easily see around the blinds we’ve built for ourselves. I don’t know if she’d grok a Monad (I don’t), but it’d be a fascinating discussion.
Rhonabwy 