Arto Bendiken

Speaking fondly of an operating system usually misconstrued by a younger generation as merely an ancient text editor older than Stallman's beard, Steve Yegge states that "Emacs is the world's last Lisp Machine. All the rest of them are at garage sales."

While that's indeed the case in a strict sense, in a slightly wider sense the essence of the legendary Lisp machines has managed to survive to the present day in at least one other closely related fork in the road, namely the Squeak project. And now, from Dan Ingalls — the original designer of Squeak and one of the fathers of Smalltalk — comes Lively Kernel, a self-hosting, metacircular prototyping and development environment implemented in JavaScript, a programming language that itself has considerable Lisp ancestry.

Ingalls and the Lively Kernel team aim at nothing less than a bottom-up rethinking of the present-day web development stack. They've recreated, in less than 10 KLOC of JavaScript, a foundation that demonstrates the benefits of systematically and unapologetically examining your assumptions and mercilessly throwing all possible incidental complexity out the window.

Lively Kernel is still at a very early stage, but watching Ingalls's presentation at Google and subsequently playing with the system I experienced much the same "wow factor" as when first encountering Squeak many years ago. Here's one phrase I would like to hear more often: "it's not complicated; it's really easy". No cathedrals being built, here!

True to its intellectual heritage, the Lively Kernel system is "live" in a manner fundamentally unlike even the best mainstream programming environments today. Ditch all existing preconditioned primitive notions of tedious edit-compile-run-crash-debug-rinse-repeat cycles, and jump right in to reprogram the system from the inside out, your changes instantly taking effect as you go along (there is a good demonstration of this in the aforementioned video when Ingalls, on the fly, reverses the time flow in a running clock widget).

As anyone who has used Squeak knows, the immediacy of this way of working is addicting, the unfettered malleability of pure thought stuff giving rise to analogies of, say, sculpting clay &mdash a stark contrast to the all-too-familiar constant friction and resistance of a bureaucratic chain of command founded in long-obsolete metaphors of folders and files, or the often arbitrary and unproductive distinctions between compile time and runtime.

This is powerful stuff, and yet the implementation code is, as Ingalls says, very straightforward indeed. The core of Lively Kernel is a reimplementation of Morphic, John Maloney's ingenious user-interface framework that also formed the basis for both Squeak and an earlier Sun Labs research project, the Self system — the latter which, incidentally, was another major influence on the design of JavaScript. The graphics primitives in Lively Kernel are based on SVG, which means that, as in NeXTSTEP and Mac OS X, all output is inherently scalable to any desired resolution. (There is an in-depth technical overview available for those who want to dig deeper into Morphic and Lively Kernel's architecture.)

One marked difference to Squeak appears to be the abandonment of a pure image-based environment, where the current snapshot of the code base would be stored e.g. in an opaque, system-specific binary format. While serialized "live images" have historically been one of the distinguishing features of Smalltalk systems (and indeed Common Lisp systems), they have not contributed to interoperability with more primitive systems (i.e. Unix) and hence have served as impediments to more widespread adoption.

The near-term roadmap for Lively Kernel seems to include WebDAV-based over-the-wire serialization, which suggests to me that e.g. Subversion (specifically, Apache's mod_dav_svn) could eventually serve as a Lively Kernel repository. If so, this would preserve the considerable advantages of image-based environments while doing away with the major perceived disadvantage.

Of course, given that I'm praising simplicity here, I would be remiss not to mention that WebDAV and DeltaV do suffer from considerable complexity bloat (as I know all too well from painful close-range exposure), and a much simpler REST and JSON-based alternative is not difficult to imagine. However, at some point you do have to interface with the external world in all its decadent glory; I think the ability to piggyback on an existing revision control system might be a worthwhile trade-off in this case.

The Lively Kernel interface at present still feels slightly sluggish, but the project's timing is most opportune. JavaScript is already today one of the most widely-deployed programming languages of all time, with an existing installed base in the hundreds of millions. The imminent next generation of browsers — Firefox 3 and IE 8 — will bring some pretty significant overall JavaScript performance boosts, not to mention that some Firefox version a little further down the line is set to integrate Tamarin, the native-code-compiling JavaScript 2 engine that will run circles around many of the sundry popular "standalone" scripting languages. JavaScript is clearly set to become the lingua franca of the next decade, and Lively Kernel provides an early glimpse of the ride we may be in for.

Yegge remarks "Lisp Machines pretty much had it nailed, as far as I'm concerned", to which I can only say: amen, brother. It seems a peculiar world where our best hope for advancing the state of the art consists of merely attempting to duplicate half-forgotten, decades-old good ideas in newer more-devolved programming languages, but such truly is the myopic, amnesiac reality of "worse is better".

On the other hand, efforts such as Lively Kernel remind us that heretofore passed-by opportunity lies right off the beaten path, on the divergent grassy road just wanting some wear. To paraphrase Ingalls's long-time collaborator, the equally industrious and illustrious Alan Kay: it seems that in an industry stuck on a repeat loop of variations on Greenspun's Tenth, the best way to predict the future may simply be to rediscover it.