The Xerox Alto, Smalltalk, and rewriting a running GUI

Be sure to read the comment from Alan Kay at the bottom of the article!

We succeeded in running the Smalltalk-76 language on our vintage Xerox Alto;
this blog post gives a quick overview of the Smalltalk environment.
One unusual feature of Smalltalk is you can view and modify the system's code while the system is running. I demonstrate this by modifying the scrollbar code on a running system.

Smalltalk is a highly-influential programming language and environment that introduced the term "object-oriented programming" and was the ancestor of modern object-oriented languages.1
The Alto's Smalltalk environment is also notable for its creation of the graphical user interface with the desktop metaphor, icons, scrollbars, overlapping windows, popup menus and so forth. When Steve Jobs famously visited Xerox PARC, the Smalltalk GUI inspired him on how the Lisa and Macintosh should work.2

Our Xerox Alto running Smalltalk-76.

The Alto was a revolutionary computer designed at Xerox PARC in 1973
to investigate personal computing. It introduced the GUI, high-resolution bitmapped displays, WYSIWYG editors, Ethernet, the optical mouse and laser printers to the world, among other things.
I've been restoring an Alto from YCombinator, along with
Marc Verdiell,
Carl Claunch
My full set of Alto posts is here and Marc's extensive videos of the restoration are here.

The desktop

Smalltalk introduced the desktop metaphor used in modern computing.3
It included overlapping windows4, multiple desktops and pop-up menus.
These windows could be moved and resized with the mouse.
(The biggest missing desktop feature was desktop icons, which Xerox later introduced in the Star computer.)
To understand how revolutionary this was, consider that
the Apple 1 microcomputer came out in 1976,
displaying 24 lines of 40 uppercase characters.
The mainframe and minicomputer worlds were focused around punched cards, line printers, Teletypes, and dumb CRT terminals.
Alan Kay changed all this with his vision of a computer desktop with windows that could be directly manipulated, windows containing fancy typography or images.

The screenshot above shows the Smalltalk-76 desktop. At the bottom, a drawing program displays the Smalltalk elf image.5
Icons allow selection of drawing mode, line style, brush color (grayscale), and so forth.
The Smalltalk class browser is in the middle.
In the upper right is a file viewer. Finally, in the upper left is a window for entering Smalltalk statements, essentially a shell or REPL.

Dynamically changing the running system

One of the most interesting things about the Smalltalk environment is that all the Smalltalk code can be examined and modified, even while the system is running.
The class browser below lets you select (using the mouse) a functional area such as "Basic Data Structures" or "Files". You can then select a class in that area,
functionality within the class, and then a particular method. The browser then displays the code running on the system.
All the Smalltalk code can be examined in this way, making the system's implementation very transparent.

Using the Smalltalk class browser, we can view the code to show a ScrollBar.

In the screenshot above, I use the class browser to access "Panes and Menus", then "ScrollBar", then "Image" and finally "show". This displays the code for the scrollbar's "show" method, which draws the scrollbar.
This code draws a black rectangle, and then insets a white rectangle, resulting in a black-bordered rectangle for the scrollbar.
(Note the unusual dotted-circle character ☉ that Smalltalk-76 uses to create a Point from two Numbers.)

The unusual feature of the class browser is that you can use it to change the system's code, while the system is running, and everything will pick up the new code.
For example, I can change how scrollbars are drawn.
In the screenshot below, I changed clear: white to clear: black.
Pressing the middle mouse button pops up a menu, and I can select "compile".
This causes the scrollbar code to be recompiled—while the system is still running.
(Note the modern appearance of the contextual pop-up menu.)

After changing the code, I selected "compile" from the pop-up menu.

The result of this change is that all scrollbars (for existing or new windows) will now have a black background, as you can see below.
The key point is this change was made while the system was running; there is no need to restart anything.
Even existing windows get the new scrollbars.

Scrollbars now appear with a black background, even for existing windows.

Although this scrollbar change was rather trivial, major changes can be made to the running Smalltalk system.
One well-known story of changing Smalltalk's behavior on the fly is from Steve Jobs' visit to Xerox PARC. Steve Jobs didn't like the way the window scrolled line-by-line, so Smalltalk implementer Dan Ingalls rewrote the scrolling code in a minute and implemented smooth scrolling while the system was running, much to Jobs' surprise.6

A closer look at some Smalltalk code

In Smalltalk, even most of the math functions are written in Smalltalk.
For instance, suppose we wonder how square roots are computed.
We can look at the square root function in the class browser by going to "Numbers", "Float", "Math functions", "sqrt".
This brings up the seven lines of code below for the square root function.
We can see that the code uses five iterations of Newton's method to approximate the square root.

Looking at the square root code in the Smalltalk-76 class browser.

If you're used to Java or C++, this object-oriented code may look strange, especially since Smalltalk uses some strange characters.
The first line of code above defines local variables guess and i.
In the next line, the right arrow ⇒ implements an "if" statement.
If the number receiving the square root message (self) is 0, then 0 is returned (via the up arrow ⇑ return symbol) and if it is negative an exception is raised.
The square brackets define blocks, similar to curly braces in C.
The instfield line is a bit tricky; it pulls the exponent out of the floating point number and divides it by 2, yielding a reasonable starting point for the square root.
Finally, the for loop applies Newton's method 5 times and returns the result. Note the unusual double colon symbol ⦂; this delays evaluation of the argument, so it can be evaluated multiple times in the loop.7

You might think that executing Smalltalk code for math operations would be very slow, and that is the case.
The good news is that basic operations such as addition are implemented with short cuts, rather than full message passing. But other operations are slow; the team described performance as between "majestic" and "glacial".
Xerox PARC ended up creating the Dorado, a much faster minicomputer than the Alto, to improve performance.

Conclusion

Although Smalltalk wasn't the first object-oriented programming language, Smalltalk introduced the term object-oriented programming and was very influential in later object-oriented programming languages.
Most modern object-oriented languages, from Objective-C and Go to Java and Python, show the influence of Smalltalk.
Smalltalk was also responsible for design patterns. The famous "Gang of Four" Design Patterns book
describes design patterns in Smalltalk and C++.8

Smalltalk systems are still in use.
Smalltalk-76 (and the earlier 71 and 72 versions) were intended for research, but
Xerox released the Smalltalk-80 version; it was licensed by Xerox to HP, Apple, Tektronix and DEC for royalty-free distribution.
Smalltalk-80 in turn led to modern Smalltalk systems such as
Pharo, GNU Smalltalk and Squeak (which led to the Scratch language for children).

If you want to try Alto Smalltalk out for yourself, you can use the Contralto emulator, built by the Living Computers Museum. I explain how to run it here.
(Most of the screenshots above are from Contralto rather than the live Alto, for clearer images.)
Be warned, however, that Smalltalk on the Alto (live or emulated) is painfully slow.

Notes and references

Smalltalk was developed on the Xerox Alto by Alan Kay, Dan Ingalls, Adele Goldberg and others. ↩

The details of Steve Jobs' visits to Xerox PARC are highly controversial but the description in Dealers of Lightning seems most accurate. ↩

Englebart's Mother of All Demos was fundamental to the development of the GUI, introducing the mouse and windows, among other things. This demo had a large influence on Xerox PARC. ↩

For performance reasons, only the foreground window was active and background windows were not redrawn. ↩

Screenshots of Smalltalk-76 very often include the lute-playing elf image, so I tracked down the image and figured out how to display it.
The command is BitRect new fromuser; filin: 'elf'; edit. This creates a new BitRect object and gets the dimensions from the user. Then it sends a filin: 'elf' message to the BitRect, which performs file input from the elf.pic file.
Finally, an edit message is sent to the BitRect, causing it to be opened in the image editor. ↩

For details on Dan Ingalls' live implementation of smooth scrolling in Smalltalk-78, see
this page. The story is also in Dealers of Lightning, page 341. (Dealers of Lightning is the best book I've come across describing Xerox PARC and the development of the Alto.) ↩

People often think of design patterns as a Java thing, but the Design Patterns book was published in 1994, prior to Java's release in 1995.
The original design patterns referred to C++ and Smalltalk. ↩

15 comments:

A couple of comments. Dan made the scrolling change in seconds not a minute. And a more wonderful part of this demo was when Steve didn't like the complementing convention for selections and said "Can't you do an outline?". That seemed as though it might be difficult but Dan quickly duplicated the complement code and shifted the second one down and over by (I think) [email protected] This had the effect that the middle of the complementing was recomplemented, and what was left was a nice outline! A brilliant piece of thinking!

There were icons in Smalltalk long before Star. This can be seen in a variety of historical pictures and documents. Also, one of the main designs for Star was called "SmallStar" and was done in Smalltalk (primarily by David Canfield Smith).

The main speed problems on the Alto came from not enough memory (mostly because a planned successor for the Alto did not get funded). This required 2nd gen systems like Smalltalk-76 to try to optimize in very confined circumstances. We could have used more than the 1k microcode instructions, and we could have used a lot more than 128k bytes of RAM. That said, the OOZE object swapping system to the Diablo disks (they were not really a 2nd level memory) done by Dan and Ted Kaehler was quite marvelous in allowing us to function at all in the mid-70s.

Thanks for another great Alto article! The more you cover the features of the Alto, the more amazed I am. The fact that the Smalltalk environment could be re-compiled on the fly is another impressive capability. Also, thank you Alan Kay for your additions.

A few more notes. You are running a version of Smalltalk that is also using a decompiler to save space on very small machines (like the NoteTaker). I can tell this because the instance variables are in terms of "t1", "t2", etc. The string names of the variables take space, and they can be removed. What you see in the browser is the result of a really nice translator (by Alan Borning) that turns the byte codes back into editable text. (This would be a better demo with a more regular version of Smalltalk-76).

Sketchpad and Simula can't be praised too highly. However, I made up the term "object-oriented" for a system that sends and receives -messages- and has the late-bound characteristics of Smalltalk (but not Simula or the later C++, etc.). Smalltalk was a success, so the term "object-oriented" was "colonized". This has forced us into using terms like "real objects" when trying to talk about Smalltalk.

One example of this is that Ken found it interesting enough to remark (in 2017, 45 years after Smalltalk started working) that Smalltalk can make any change while it is running. To me, this is a terribly sad commentary on the state of things today. Back then we were following in the footsteps of Lisp (especially Interlisp) which was one of the pioneers of "always running systems". If you reflect that the Internet is also an "always running system" and that Smalltalk and Interlisp were developed by the same research community, we can see that the regular world still has difficulty with what systems could be.

I think Alan's final thought is what I agree with most strongly. The whole UNIX ethos has been a huge drag on industry progress. UNIX's pitch is essentially: how about a system of small functions each doing discrete individual things... but functions must all have the signature `char *function(const char *)`? Structured data is for fools, we'll just reductively do everything as text. What we had in 1972 is fine. Let's stick with that.

I completely agree with all the remarks about "while the system is running". I don't think I ever saw a worling Alto, but I have met people who either worked or visited PARK back in the 70s.

My own anecdote about "while the system is running" comes from a BBC Horizon documentary about Cosmology and the Big Bang. Part of the story took place at the Max Plank Institutes Supercomputing Centre in (I think) Hamburg, Germany. One of the physicists was talking about their simulation model of the early universe and how it was making larger and larger files, eventually reaching 1TB! This meant changing a file management routine, but the time it would take to stop the simulation and restart it would cause big problems so he rewrote the code on the fly while it was running. He likened it to "doing open heart surgery while the patient was awake"!

And to think that you could do this 40 odd years ago with Smalltalk. Very nice article Ken.

> In your now-famous OOPSLA '98 talk, you mention an early application of indirection and late binding - a tape having jump tables at the beginning. Do you have more back-story on this?

I can't speak for Alan Kay here, but this sounds an awful lot like the 'model T enfilade' in Ted Nelson's JOT project (a dedicated word processor based on a tape, where lookup tables for text rearrangement were used heavily so that text far larger than available RAM could be displayed and edited in real time despite slow tape reading and writing speed).

JOT had an implementation by Steve Witham (though I think there was another earlier implementation), and IIRC was associated with 'ibm' (the itty-bitty-machine company), but I'd need to double-check. The marketing slogan was "Edit War and Peace on a casette tape". I don't believe units were ever shipped. So it goes.

The "indirection and late-binding on tape records" is explained in "The early history of Smalltalk" (easily found online). In short it was an approach to interoperability using one of the earliest "almost-object" ideas (in Burroughs 220 machine-code, etc). The system was in use in the Air Force ATC when I showed up in '61 ...

A side note is that the "elf" is the avatar of the Notetaker portable computer we were working on at the time (you can see a pen in his back pack). This particular painting system was done by Ted Kaehler (and was the perhaps the 4th or 5th in this progression), and I will confess to having done the painting ...

MichieldB: the cursor on the Alto was a hardware "sprite" and could be customized. Different applications used different (and sometimes multiple) cursors, but the tilted arrow was the default. Apparently PARC would change the cursor for holidays, e.g. a heart for Valentines. Alan Kay could probably tell you more about the history.

There is a lot to assume about the shape (it improved visibility, has the angle of a right hand finger pointing), but I am hoping to find a research paper on it from PARC ;) I did find a paper on the mouse, but it does not mention it's pixel design. There are also some papers on icon design, so who knows...