Self
Self is an object-oriented programming language based on the prototype-based programming paradigm. It was used mainly as an experimental test system for language design in the 1980s and 1990s. In 2006, Self was still being developed as part of the Klein project, which is a Self virtual machine written fully in Self.
Self was designed mostly by David Ungar and Randall Smith in 1986 while working at Xerox PARC. Their objective was to push forward the state of the art in object-oriented programming language research, once Smalltalk-80 (ST80) was released by the labs and began to be taken seriously by the industry. They moved to Stanford University and continued work on the language, building the first working Self compiler in 1987. At that point, focus changed to attempting to bring up an entire system for Self, as opposed to just the language.
The first public release was in 1990, and the next year the team moved to Sun Microsystems where they continued work on the language. Several new releases followed until falling largely dormant in 1995 with the 4.0 version. The 4.3 version was released in 2006 and ran on Mac OS X and Solaris. A new release, version 4.4, has been developed for MacOS X and Linux by a group comprising some of the original team and independent programmers and is available for Mac OS X and Linux.
Self also inspired a number of languages based on its concepts. Most notable, perhaps, was the NewtonScript language for the Apple Newton and the JavaScript language used primarily for dynamic web pages in all modern browsers. Other examples include Io, Cel, Lisaac and Agora. The IBM Tivoli Framework's distributed object system, developed in 1990, was, at the lowest level, a prototype based object system inspired by Self.
Klein
Klein is a virtual machine for the Self language, written entirely in Self, and a development environment for that VM. The project is named after the Klein bottle. Following is an excellent excerpt from the Self blog about how the fundamental differences between the Klein and Squeak VM's.
I believe that a Klein-like VM has the potential to be more object-oriented and more interactive than a Squeak-like VM. But one of the costs of the Klein approach is that we can’t reuse existing compilers the way Squeak does.
One of the cool things about the Squeak VM is that by writing it in a subset of Smalltalk, they were able to use the standard Smalltalk environment to write and debug the VM, while still taking advantage of all the work that’s gone into implementing C compilers. Writing in restricted Smalltalk is still nicer than writing in C, and debugging a simulated interpreter using the Smalltalk debugger is nicer than using a C debugger. (And while GCC isn’t written in Smalltalk, the Squeak guys don’t have to maintain it, so who cares?)
In contrast, one of Klein’s goals is to write the entire VM in a normal, high-level, object-oriented style. This includes the compiler and the assembler and the garbage collector and the interpreter (if we someday decide that we want an interpreter) and the object-format subsystem and everything else. So far, I believe we’ve only had to “cheat” (dip down into a lower-level style) in two small places: we had to write the message-sending routine without doing any message sends, and the object-cloning routine without doing any cloning (which meant we couldn’t use blocks). But I believe that even those compromises are just temporary – now that we’ve got a compiler that can inline away message-sends and block-clones, we should be able to rewrite even those two routines in a normal OO Self style.
So we’ve had to write our own compiler ourselves, and we’ll have to maintain it and port it ourselves. But the payoff is that the whole VM can be written in full OO Self, and be a live part of the running Klein image.
Which brings me to the other big difference between Klein and Squeak: in Squeak, the running VM isn’t part of the image. If you use the Squeak environment to make a change to the source code of the Squeak interpreter, the currently-running Squeak system doesn’t immediately change – you have to re-run the Slang-to-C translator and rebuild the VM and restart the image. (You can use Squeak to run a simulated Squeak interpreter, and make changes to the source code of the interpreter and see the changes immediately take effect in the simulation. But you don’t get that kind of interactiveness in the real base-level Squeak.) And if you want to debug the Squeak VM, you have to either use C tools to debug the real VM, or you have to recreate the bug in the simulator and use an existing Squeak to debug the simulated Squeak.
(Someone please correct me if I’m wrong. I haven’t spent a lot of time playing with the Squeak VM. This is just how it seems to me, given my understanding of Squeak’s architecture.)
In contrast, the Klein VM code is all just a regular part of the running Klein image. The project isn’t far enough along yet for us to be able to hack on Klein while it’s running, but once we get there, we should be able to make changes to the running VM and see those changes take effect immediately. (I expect this to be both very useful and very dangerous – a tradeoff Smalltalkers are used to. :) ) So when we debug the Klein VM, we’re looking at the real, running, compiled code, using the standard Self environment.
A third difference is that in Klein we intend to – and for performance reasons we pretty much have to – implement Self’s dynamic optimization tricks, whereas I don’t think the current Squeak VM does much of that kind of thing. But I don’t think that’s a fundamental limitation of the Squeak VM architecture. (I’m excited about Cog!)
