These days, it’s hard to appreciate that Object-Oriented Programming is so easy, it was taught to kids in junior high before it was ever taught to adults. As supposedly senior software engineers debate whether a Car truly “is a” Vehicle, and whether it wouldn’t be easier to learn lambda calculus and determine the median monad blog post than to reflect the real objects in the real-world problem they’re solving in their software, it seems reasonable to ask: is it really so difficult?
Were we to walk into Xerox’s Palo Alto Research Center in 1972 and ask the creators of Smalltalk and Object-Oriented Programming, they would tell us that the problem is one of preconception. As Adele Goldberg recalls, they knew that they would have to “bootstrap” a new understanding of computing. People who already knew how to use PL/1 or SNOBOL would struggle to adapt to the Smalltalk way of doing things, but children who learned how to think about objects and the iterative, incremental approach to computing they encourage would take that understanding with them their whole lives.
Adele Goldberg was hired into the PARC team in 1972 after Alan Kay discovered her work at Stanford on teaching computing. In the past she had taught “comparative” programming: getting students to implement features from each of SNOBOL, PL/1, and BAL in the other languages to understand how each supported different concepts in different ways. The PARC team had an arrangement with a local junior high school to teach Smalltalk, and also held classes for the children of Xerox staff on Saturdays.
Smalltalk-72 had objects and messages, but was very hard to learn. An object could process messages in multiple ways: it could consume the message, it could respond to it but leave it alone, or the object could respond to the message, modify it, and put it back on the stack. All of this made it hard to understand what behaviour would result from a system of objects collaborating with a given chain of messages.
Smalltalk-72 took the approach that the syntax was defined by the receiver of the message: the receiver read as much of the message as the receiver’s method determined and then passed control to the next remaining token, which was seen as the receiver of the remainder of the message. This design came out of our assumption that the system user should have total flexibility in making the system be, or appear to be, anything that the user might choose. However, this meant that the only way that a reader could understand an expression was to execute the methods in his head. Furthermore, if a human could not parse an expression without executing the methods, the system itself would not be able to parse it. Thus Smalltalk-72 was a purely interpretive system, and its performance suffered accordingly.
So, over the next few years, with Goldberg’s expertise in education enriching the team, Smalltalk-72 became Smalltalk-76: goodbye, “message gobbling”, but also goodbye “Myrtle the Turtle”, a nod to the Logo environment from Seymour Papert‘s group. Hello, abstraction of objects into “classes” of related “instances”. Smalltalk-76 would get shown by Goldberg and programmer Dan Ingalls to the executives and product development team at a small local startup Xerox had an interest in, but that needed an injection of fresh ideas: Apple, of course, took those ideas and ran with them.
As Smalltalk development plateaued, Goldberg realised that while their work in education was interesting and valuable to the world of education, it didn’t either produce anything that Xerox management could use nor help to bring the original concept – Alan Kay’s personal computer for children of all ages – to fruition. They needed a community, and they needed goals for users of Smalltalk to want to try to achieve. She needed users and their trials and retroflections.
In her telling of the history, this is an issue on which she and Alan Kay diverged. He thought that if Smalltalk gained “customers” then they would have to support their needs, and lose a lot of creative flexibility. Adele Goldberg thought that having customers would improve their understanding of the experience of having and using Smalltalk and its concepts, providing useful feedback.
Whatever the internal discussions or conflicts, the community view won, and Smalltalk-80 was developed much more in the open. Collaborators from Xerox (beyond PARC), Hewlett-Packard, Tektronix, and elsewhere shared machines, source code, “bits of history, and words of advice”. Smalltalk-80 was introduced to the world in Byte Magazine, in which Adele Goldberg contributed the introduction alongside an article co-authored with Joan Ross, “Is the Smalltalk-80 System for Children?” (from which the above quote about Smalltalk-72 was taken).
Eventually, much later than Goldberg anticipated, a series of three books about Smalltalk-80 were published: Adele wrote Smalltalk-80: the Interactive Programming Environment, also known as “the red book”, which is a guide to using and extending (the same thing, really) the Smalltalk-80 system. She co-authored Smalltalk-80: The Language and its Implementation, “the blue book” that dives into the details of how the system works.
The third book in the series, “the green book”, is Smalltalk-80: Bits of History, Words of Advice, a collection of essays edited by Glenn Krasner on the experiences of implementing and using Smalltalk-80. The essay provided by Adele Goldberg, the first in the book, describes the review and release process that got Smalltalk-80 from an initial tape containing the 164 kB virtual machine image to the final version incorporating the changes and suggestions of the community. Sadly, a fourth book on application design (“Smalltalk-80: Creating a User Interface and Graphical Applications”) never appeared, an absence which undoubtedly fuelled the explosive growth of the “articles interpreting Model-View-Controller” industry.
Taken together, the red and blue books act like a progressive reveal of the way Smalltalk-80 works. Here’s how you use the UI and enter text; here’s how you run that text as Smalltalk-80; here’s how you integrate that Smalltalk-80 into the rest of the system; here’s how that Smalltalk-80 gets compiled into bytecode; here’s how that bytecode gets interpreted by the virtual machine. But the amazing tour de force is that there’s another book in there, too. If you read backwards from the end of the blue book, you have a literate program describing the implementation of an object-oriented programming environment: here’s a garbage collector; here’s a language runtime that uses that garbage collector; here’s a compiler that targets that runtime; here’s a programming system leveraging that compiler, and so on.
But where a Knuth literate program is an essay explaining how a particular program works, the blue and red books describe how Smalltalk-80 is designed. There are multiple listings given for the same routine, refined as new ideas are presented. Here’s how you allocate space for an object. Now that we’ve got automatic reference counting, your allocator also needs to zero the count. Now that we’ve got a mark/free collector, your allocator can compact memory if there isn’t enough space. And we didn’t show you what to do differently for strings and compiled methods.
When it became evident that Xerox management weren’t interested in commercialising PARC’s computing ideas, Goldberg and others formed ParcPlace systems, a spin-out company to capitalise on Smalltalk-80 (thus furthering her goal of finding real users with real problems to solve). Through her work in various roles in the ACM, including president, Goldberg initiated the OOPSLA (Object-Oriented Programming, Systems, Languages, and Applications) conference series and further promoted the concepts and applications of OOP.
A good idea doesn’t survive on its own, it needs to be communicated, adopted, and extended. Adele Goldberg’s background in computers in education, her community engagement, and her simple, direct writing style shaped the direction of the entire software industry for decades.
Cover image courtesy of the Squeak wiki. Links to books about Smalltalk-80 provided by Stephane Ducasse at INRIA, on behalf of the authors. We gratefully acknowledge the generosity of these people for sharing their work.
