So what's the symbology there?

As I read the opening chapter of Paul Dourish's Where the Action Is, I couldn't help but pause to reflect on the phases through which interaction has evolved over the years: electrical, symbolic, textual and graphical. Dourish characterizes the transition between phases as "a general trend that emerges in a number of different ways"(7). What he didn't mention is that each new interaction paradigm has served to supplement the former in a continual coevolution. This coevolution will be essential as we try to make the most of the new devices and manifestations of computational power, particularly with relation to multi-core and distributed processing.

As a mathematician and language geek, I'm most drawn to interaction optimizations at the symbolic level. Through my programming career, I've been exposed to dozens of symbolic abstractions, ranging from Logo and my TI-85 to academic amusement with Scheme to "real-world" languages like C and Java. For the most part, however, the languages have been more similar than different. And with the exception of a course on functional languages, the style of programming was always the same: tell the computer how to push these bits around. For the majority of problems, that was simple enough, particularly with the steady march of CPU speeds in step with Moore's Law.

Well physics decided to step in the way of our 20-GHz CPUs, leaving us instead with dual- and quad-core systems. There's still an increase in processing power, but taking advantage of it requires new ways of thinking. Among these are various new (or new-again) symbolic abstractions that will be essentially to get developers back to the point where the electrical systems are sufficiently hidden that we can get on with the real work of building the next generation of textual and graphical interfaces. As a developer on the Microsoft platform, there are two in particular that are of interest: Axum and F#.

Axum

According to Microsoft, "Axum is a language that builds upon the architecture of the Web and principles of isolation, actors, and message-passing to increase application safety, responsiveness, scalability, and developer productivity." In other words, it's a domain-specific language (DSL) built specifically for scenarios involving distributed and concurrent computation. I haven't built anything with it yet, and at this point it remains very much experimental, but the concept has a lot of promise to faciliate the creation of applications and frameworks that can seamlessly handle the new architectures that have emerged. For more information, check out the Axum page on MSDN.

F#

Functional languages have been around for a very long time, and they are based on the lambda calculus which has been around even longer. But only recently have they started to come back into mainstream view, due in part to new functional languages for the major development platforms: Clojure and Scala for the Java Virtual Machine, and F# for .NET. The other reason for this comback is the ease with which functional languages handle the problem of concurrency through the use of immutable values and data structures. These languages also provide other higher-level abstractions that move developers away from specifying "how to push these bits around" and more toward specifying what they are trying to accomplish.

In both cases, there is clear value in solving the difficult problems once and letting symbolic abstractions shield the rest of us from ever having to think about it at a low level. It will always be necessary to have some knowledge of what's happening behind the scenes, just as managed memory doesn't free the developer from memory considerations completely. But leaning on advanced symbolic abstractions is one more way to advance the state-of-the-art in HCI.