The slides that follow give an overview of some of the highlights of the work I've done over the past few years. More detail is provided on individual project pages.
Please click on the
> links to page through the slides, or choose a slide from the list of titles above.
RabbitMQ and AMQP
RabbitMQ is an implementation of AMQP that I've worked on since late 2006. It's an interesting project in a number of ways: it's polyglot; it's theoretically interesting; it's deeply practical; and it has a large and engaged community around it.
The system's heart, the server, is written in Erlang, and there are RabbitMQ client libraries in lots of other languages and environments, but it's polyglot in a different sense, as well: the gateways to other kinds of messaging network that I've built let RabbitMQ translate fluently from one messaging style to another. Each gateway's construction has taught me new things about the essence of messaging: about addressing, naming, querying, routing, topology and security. I expand on this a little on the next slide.
The implementation makes use of a lot of interesting distributed-systems theory (mainly relating to transactions, effect visibility, and different kinds of consistency), but is also a system that serious industrial software is built upon, which helps ground the project in real-world software engineering issues. The community is great for giving feedback, sharing how they're using the system, and helping each other out with problems they face, from architecture to fine points of the use of the APIs we've designed.
As part of my work on RabbitMQ (see previous slide and also here), I've become increasingly interested in network architecture: the problems of IPv4 and IPv6 at scale, the design challenges in AMQP, the awkwardness of programming for the web and around firewalls, the poor state of multicast.
After a couple of years of fumbling around various design points as a member of the AMQP working group, I stumbled across John Day's book Patterns in Network Architecture (which I recommend). His emphasis on a single-layer recursive architecture helped structure the ideas I'd had around such things as reversehttp and the AMQP 1.0 design effort, and some of the basic experiments I've done subsequently in multicast and bittorrent-style state synchronisation, along with the experimental gateways to XMPP and PSHB have led to new ideas that I'll be writing up and implementing over the next few months.
The questions I'm currently looking at include: What does a relativistic, recursive naming system (that isn't bang-paths) look like? How might we secure and manage our overlay networks and VPNs, especially those in the cloud? How could programming languages and networking fit together better?
Programming Languages and Operating Systems
I'm a fan of Dan Ingalls' statement, "An operating system is a collection of things that don't fit into a language. There shouldn't be one." With that in mind, I've been exploring both operating system kernels and programming language technologies over the past several years.
Commercially, the most significant PL project I've worked on has been Microsoft Highwire, where I developed an extensible syntax and macro system, designed visual representations of process calculi, and contributed to the design of various behavioral type systems for processes. The illustration above is an automatically-derived control flow visualization of a simple program written in a π-calculus-like process language, produced as part of Highwire.
Most of my personal, non-commercial projects explore areas of PL and OS design. I'm fascinated by the potential of partial evaluation, pattern-matching, and reflection as practical tools for software engineers; see here for details. Many of my experiments in these areas rely on the extensible parsing libraries I've produced. Newmoon, my Scheme compiler, has been growing since 2003, and this page describes some of the other little languages and runtimes I've built. Finally, the series of simple Minix-inspired microkernels I've written over the years has taught me a lot.
Since VR made its first big splash in the media in the early nineties, I've been exploring the idea by building simple VR software.
After reading about Smalltalk's image-based persistence1, about LambdaMOO, and having built a few little languages, and a BBS to get my head around concurrency and communication, I started building experimental adventure-game-style systems, culminating in 3-move, a multi-user networked online text-based programmable virtual environment. The illustration above shows a user exploring a world (via a simple curses-based MUD client I wrote).
3-move has its own programming language with a built-in permissions model and a simple extensible adventure-game-style command parser; as an example of both, this code provides an
edit verb for an in-game notepaper object.
I became interested in digital audio in 1998, after being exposed to Haskore in my Functional and Logic Programming course. Wanting to work directly with audio samples, rather than via MIDI at one remove as Haskore did, I started reading what literature I could find in the university library on DSP for computer music. I first built a series of command-line pipelineable tools for manipulating PCM data. Using the experience gained from those, I built a Haskell- and Haskore-inspired programming language for manipulating sampled sound. Finally, I built gAlan (illustrated above), a graphical environment for constructing sound processing pipelines.
Syncing State using Distributed Version Control
Many problems in distributed systems can be viewed as stylized interactions with a distributed version control system (DVCS). It's an unusual way of looking at the world, but lots of problems involve sophisticated state synchronization, which is what DVCS is all about.
For in-browser display of revision history, I ad-hoced together an algorithm for laying out ancestry DAGs (see illustration). I was surprised to realise later that the layout task looks startlingly similar to (a simplified form of) register allocation, leading me to wonder: which allocation algorithm have I reinvented in different guise?
With a careful choice of merge algorithm, DVCS can be applied to many domain-specific datasets. For example, TCP, Bittorrent, and Google Wave can all be viewed abstractly as (degenerate cases of) DVCS pushes and pulls, with a domain-specific dataset and merge algorithm. Distributed systems often use vector-clocks: it'd be interesting to explore the relationship between vector-clocks and change history.
Modelling Biochemical Pathways
Attending BioConcur '04 led to some interesting thinking about possibilities for modelling biomolecular processes using π-calculus-like languages. A few weeks after the conference, my thoughts crystallized into a new join-calculus-based programming language, StoJ, for exploring description, simulation, and visualization of biochemical systems modelled as concurrent, rate-limited processes.
Besides producing process simulation data, the system can automatically transform a process description into a visual form reminiscent of standard biochemical reaction schematics. The picture on the left is a diagram produced automatically by StoJ from a model of
HCl dis- and re-association.
See here for links, downloads, and more discussion.
Openmoko, Widgets and Personal Computing
For a long time—ever since realising that user interfaces had scarcely advanced since 1980—I've been dissatisfied with the languages provided for interacting with personal computing facilities, such as they are, and have been interested in trying to improve the situation.
In 2007, I bought an Openmoko cellphone, to see if it could be shaped into a personal computing environment. I discarded its userland, keeping the kernel, X11 and core libraries and building my own replacement modem driver, dialer (illustrated on the right, above), address book and so forth. To do so, I ported Erlang to the phone, and contributed the scripts to Openembedded.
After hitting the frustrating limitations of GTK+, I started using GNU Smalltalk, Cairo, and SDL to build a simple, lightweight widget set (illustrated on the left, above) instead.