Squeak is like an operating system

The Squeak 3.9 desktop

In foreground is a System Browser (what I call a “code browser”–the default developer IDE), and one of the desktop “flaps” on the right (like a “quick launch” bar–it retracts). Behind the System Browser is the Monticello Browser, a version control system for Squeak. The bar at the top contains some system menus and desktop controls. The wallpaper is called “Altitude”.

Smalltalk is misunderstood. It’s often criticized as one big lock-in platform (like Microsoft Windows, I guess), or as I saw someone say, a “walled garden”, or more often a language that’s “in its own little world.” I think all of these interpretations come about because of this misunderstanding: people think Smalltalk is just a language running on a VM. Period. They don’t understand why it has its own development tools, and its own way of interacting. That doesn’t seem like a typical language to them, but they can’t get past this notion. The truth is Smalltalk is unlike anything most programmers have ever seen before. It doesn’t seem to fit most of the conventions that programmers are trained to see in a language, or a system.

We’re trained that all an operating system represents to a user or a programmer is a manager of resources, and an interaction environment. Programs are stored inactive on disk, along with our data files. We learn that we initiate our programs by starting them from a command line, or clicking on an icon or menu item, through the interaction environment of the OS. When a program is run, it is linked into the system via. a loader, assigned an area of memory, and given access to certain OS resources. Programs are only loaded into memory when they’re running, or put into a state of stasis for later activation.

We’re trained that a “virtual machine,” in the .Net or JVM sense, is a runtime that executes bytecodes and manages its own garbage collected memory environment, and is strictly there to run programs. It may manage its own threads, or not. It becomes active when it’s running programs, and becomes inactive when we shut those programs down. It’s a bit like a primitive OS without its own user interaction model. It remains hidden to most people. We’re trained that programming languages are compilers or interpreters that run on top of the OS. Each is a separate piece: the OS, the development tools, and the software we run. They are linked together only occasionally, and only so long as a tool or a piece of software is in use. Smalltalk runs against the grain of most of this conventional thinking.

Like its predecessor, Smalltalk-80, Squeak functions like an operating system (in Smalltalk-80’s case, it really was an OS, running on the Xerox Alto a Xerox computer). The reason I say “like” an OS, is while it implements many of the basic features we expect from an OS, it doesn’t do everything. In its current implementation it does not become the OS of your computer, nor do any of the other Smalltalk implementations. It doesn’t have its own file system, nor does it natively handle devices. It needs an underlying OS. What distinguishes it from runtimes, like .Net and the JVM, is it has its own GUI–its own user interaction environment (which can be turned off). It has its own development tools, which run inside this interaction environment. It multitasks its own processes. It allows the user to interactively monitor and control background threads through the Process Monitor that also runs inside the environment. Like Lisp’s runtime environment, everything is late-bound, unlike .Net and the JVM. Everything is more integrated together: the kernel, the Smalltalk compiler, the UI, the development tools, and applications. All are implemented as objects running in one environment.

Creating a unified language/OS system was intentional. Alan Kay, the designer of the Smalltalk language, was in a discussion recently on operating systems on the Squeak developers list. He said that an operating system is just the part that’s not included in a programming language. In his opinion, a language should be an integral part of what we call an OS. His rationale was that in order for a program to run, it needs the facilities of the OS. The OS governs I/O, and it governs memory management. What’s the point in keeping a language separate from these facilities if programs are always going to need these things, and would be utterly useless without them? (Update 12-14-2010: Just a note of clarification about this paragraph. Though Alan Kay’s utterance of this idea was the first I’d heard of it, I’ve since seen quotes from Dan Ingalls (the implementor of Smalltalk), from material written a few decades ago, which suggest that the idea should be attributed to him. To be honest I’m not real sure who came up with it first.)

Another reason that there’s misunderstanding about Smalltalk is people think that the Smalltalk language is trying to be the “one language to rule them all” in the Squeak/Smalltalk environment. This is not true.  If you take a look at other systems, like Unix/Linux, Windows, or Mac OS, most of the code base for them was written in C. In some OSes, some of the code is probably even written in assembly language. What are the C/C++ compilers, the Java and .Net runtimes, and Python and Ruby written in? They’re all written in C. Why? Is C trying to be the “one language to rule them all” on those systems? No, but why are they all written in the same language? Why aren’t they written in a variety of languages like Pascal, Lisp, or Scheme? I think any of them would be capable of handling the task of translating source code into machine code, or creating an interpreter. Sure, performance is part of the reason. The main one, though, is that all of the operating systems are fundamentally oriented around the way C does things. The libraries that come with the OS, or with the development systems, are written in it. Most of the kernel is probably written in it. Pascal, assuming it was not written in C, could probably handle dealing with the OS, but it would have a rough time, due to the different calling conventions that are used between it and C. Could Lisp, assuming its runtime wasn’t written in C, either, interact with the OS with no help from C? I doubt it, not unless the OS libraries allowed some kind of universal message passing scheme that it could adapt to.

A major reason Smalltalk seems to be its “own little world” is like any OS, it needs a large variety of tools, applications, and supporting technologies to feel useful to most users, and Smalltalk doesn’t have that right now. It does have its own way of doing things, but nothing says it can’t be changed. As an example, before Monticello came along, versioning used to only take place in the changesets, or via. filing out classes to text files, and then saving them in a version control system.

Saying Smalltalk is isolating is equivalent to saying that BeOS is a “walled garden,” and I’m sure it would feel that way to most. Is any OS any less a “walled garden”? It may not seem like it, but try taking a Windows application and run it on a Mac or Linux without an emulator, or vice versa. You’ll see what I mean. It’s just a question of is the walled garden so big it doesn’t feel confining?

Having said this, Squeak does offer some opportunities for interoperating with the “outside world.” Squeak can open sockets, so it can communicate via. network protocols with other servers and databases. There’s a web service library so it can communicate in SOAP. Other commercial implementations have these features as well. Squeak also has FFI (Foreign Functionality Interface), and OSProcess libraries, which enables Squeak programmers to initiate processes that run on the underlying OS. As I mentioned a while ago, someone ported the wxWidgets library to it, called wxSqueak, so people can write GUI apps. that run on the underlying OS. There’s also Squeak/.Net Bridge, which allows interaction with the .Net runtime, in a late-bound way (though .Net makes you work harder to get what you want in this mode). So, Squeak at least is not an island in principle. Its system support could be better. Other languages like Ruby have more developed OS interoperability libraries at this point.

The “C/C++ effect” you see on most other systems is the equivalent of what you see in Squeak. The Smalltalk language is the “C” of the system. The reason most software out there, even open source, can’t run on it, is at a fundamental level, they’re all written in C or C++. The system languages are so different. Smalltalk also represents a very different system model.

What Smalltalk, and especially Squeak, has achieved that no other system has achieved to date, with the exception of the Lisp machines of old, is a symbolic virtual machine environment that is more relevant to its own use than any other runtime environment out there. In .Net and the JVM, you just use their runtimes to run programs. They’re rather like the old operating systems at the beginning of computing, which were glorified program loaders, though they have some sophisticated technical features the old OSes didn’t have. With Squeak, you’re not just running software on it, you’re using the VM as well, interacting with it. Squeak can be stripped down to the point that it is just a runtime for running programs. There are a few Squeak developers who have done that.

In Smalltalk, rather than machine code and C being software’s primary method of interacting with the machine, bytecode and the Smalltalk language are the basic technologies you work with. This doesn’t mean at all that more languages couldn’t be written to run in the Smalltalk environment. I have no doubt that Ruby or Python could be written in Smalltalk, and used inside the environment, with their syntax and libraries intact. The way in which they’d be run (initiated) would be different, but at heart they would be the same as they are now.

Both Apple and Microsoft are moving towards the Smalltalk model, with the Cocoa development environment on the Mac, and .Net/WPF on Windows. Both have you write software that can run in a bytecode-executing runtime, though the OS is still written in large part in compiled-to-binary code. If desktop OSes have a future, I think we’ll see them move more and more to this model. Even so, there remain a couple of major differences between these approaches: Smalltalk uses a late-binding model for everything it does, so it doesn’t have to be shut off every time you want to change what’s running inside it. Even programs that are executing in it don’t have to be stopped. .Net uses an early-binding model, though it emulates late binding pretty well in ASP.Net now. I can’t comment on Cocoa and Objective C, since I haven’t used them. Another difference is, like Linux, Squeak is completely open source. So everything is modifiable, right down to the kernel. As I’ll get into in my next post, this is a double-edged sword.

Update 7/20/07: I found this in the reddit comments to this blog post. Apparently, there is a version of Squeak that IS an operating system, called SqueakNOS, that allows you to boot your computer into Squeak, as if it was an OS. The name stands for “Squeak No Operating System.” It comes in an ISO image that you can burn to CD. From the screenshot, it shows that it has a concept of devices, displaying tabs for the CD-ROM drive, serial port, and NIC.

I think I had heard the name of SqueakNOS before this, but I didn’t know what it was. The version of Squeak that most people have is the kind that rides on top of an existing OS, not this, but it’s nice to know that this is out there. Personally, I like the kind I have, since it allows me to do what I like doing in Squeak, and if I want resources it doesn’t have available, then I can go to the OS I’m running. I used to hear about a version of Linux that ran this way, so people didn’t have to dual boot, or use virtualization software. There’s no “dishonor” in it.

One person in the reddit comments said they wished it had a “good web browser that supported AJAX.” Me too. There is a HTML browser called “Scamper”, available from SqueakMap. It used to be included in the image, but in the latest version from squeak.org it looks like it’s been taken out. It seems that lately, Squeak developers have preferred the idea of having Squeak control the default browser on your system (IE, Safari, Firefox, etc.) to using a browser internal to Squeak. The last I saw Scamper, it was a bare-bones HTML browser that just displayed text in a standard system font. It could be better.

Update 1/18/20: I happened to research SqueakNOS last year for a bit, and found out it didn’t technically run as the computer’s operating system. It just acted like one. What actually happened is the computer booted into a stripped down version of Linux, which automatically ran Squeak as its sole application at boot up. This is how Chromebooks operate. My guess is the device management in SqueakNOS manipulated drivers in Linux.

This is one of a series of “bread crumb” articles I’ve written. To see more like this, go to the Bread Crumbs page.