Summary

  • Adele Goldberg and David Robson's 1983 Blue Book described a narrow interface between a Smalltalk-80 Virtual Image and each machine-specific Virtual Machine: object memory, bytecodes, execution contexts, message dispatch and primitive operations.
  • Goldberg made the specification answer to real implementations. Apple, DEC, Hewlett-Packard and Tektronix built ports, exchanged discrepancies with Xerox PARC and used reference traces to determine whether the same image behaved as expected.
  • That achievement proved portability at a defined boundary. It did not prove that different hosts had equal throughput, pauses, font metrics, windows, input devices, file behavior or interactive quality.

A specification that had to boot

A software standard can look complete while everyone still depends on the people who wrote the original. Smalltalk-80 confronted that problem in its most demanding form. It was not merely a grammar or compiler. It was a live programming environment whose classes, tools, debugger, graphics and interface existed together as objects in a persistent image. Moving it to another computer meant preserving a world, not just accepting valid source text.

The answer documented by Adele Goldberg and David Robson in Smalltalk-80: The Language and Its Implementation was a split. The Virtual Image contained the objects that made up the system. Beneath it, a machine-specific Virtual Machine supplied the interpreter, object memory and primitives that connected the image to storage, arithmetic, displays, pointing devices and other host facilities. Source methods compiled to compact eight-bit bytecodes. An interpreter executed those bytecodes while contexts represented active computations and object memory kept identity and fields coherent.

This was the portability bargain: implement the smaller machine-facing kernel correctly, then load a shared image. The Blue Book was valuable not because prose had replaced software, but because it defined enough observable machinery for another team to rebuild the missing lower layer.

Goldberg's distinctive contribution was to refuse an internal definition of “enough.” The book would be reviewed by people who had to make it work on different hardware.

The outside teams were part of the instrument

In her 2010 Computer History Museum oral history, Goldberg described first securing corporate permission to publish. With her manager Bert Sutherland's support, she then enlisted Tektronix, Hewlett-Packard, DEC and Apple. Participation required an internal software team working with a hardware team. The question was not whether engineers liked the language. It was whether features of a machine helped or obstructed Smalltalk's performance.

The release account later collected in Smalltalk-80: Bits of History, Words of Advice makes the method unusually concrete. Six companies were invited; four entered the implementation phase. The four agreed to exchange discovered bugs and design advice with Xerox and one another. They received evolving image tapes, instructions about object pointers, object space, contexts, compiled methods and classes, and telephone access when the written specification disagreed with running reality.

This arrangement turned each port into a test of the document. A paragraph could sound plausible at PARC and still fail when DEC, HP, Tektronix or Apple engineers tried to construct the corresponding VM. A behavior that depended silently on an Alto or Dorado could be exposed as an undocumented assumption. Hardware differences became questions directed back at the contract.

The participating firms were not ceremonial validators. The specification changed during the process. Primitive assignments moved. The image grew. At the first implementers' conference, participants debated reference counting, garbage collection and method caches. Goldberg records that most prose from the earlier book attempt was discarded and rewritten; the debugged formal VM specification was the part worth retaining.

The trace was a claim about behavior

Portability needed a sharper test than “the screen looks familiar.” Xerox distributed execution traces at several levels of detail. One exposed memory references, allocation, bytecodes, message sends, returns and primitive invocations. Others covered longer runs with less detail. An implementer could compare the behavior of a new VM with the expected sequence.

That matters because the Blue Book's interface was layered. Its object-memory protocol distinguished pointer, word and byte access. It defined how the interpreter found a class and method, created a context, maintained the stack, handled a failed lookup and invoked doesNotUnderstand:. It grouped bytecodes into pushes, stores, sends, returns and jumps, with extensions where 256 opcodes were insufficient. It specified families of primitives for arithmetic, collections and streams, storage management, control, input/output and system functions.

Graphics made the boundary especially visible. High-level graphical behavior—including much of BitBlt, text and display composition—lived among image objects. At some point, however, a cursor, keyboard, bitmap display or file operation met a physical machine. Primitive behavior crossed that seam. A port could agree on what the image asked for while using a different display controller, memory scheme or machine instruction sequence to provide it.

The release criterion was therefore operational and bounded. A manufacturer succeeded when its VM could “read and adopt” the Virtual Image and reproduce expected behavior. By the fourth image release, successful implementers could load the new image without modifying their VMs. That was strong evidence that the interface had stabilized.

It was not evidence that the machines had become the same.

Compatibility stopped before experience became identical

Goldberg's release chapter separates image adoption from a second, explicitly more subjective measure: actual performance on each manufacturer's hardware. The distinction is easy to lose because a shared image can make systems appear remarkably alike. The same classes and browsers may open; the same methods may compile; the same bytecode trace may complete. Yet the interactive result still depends on everything below and around the shared boundary.

Object lookup may be cached differently. Memory can be reclaimed by reference counting, tracing or a hybrid. A primitive may be microcoded, hand-written in assembly or implemented by a slower host routine. Scheduling and input polling alter latency. Screen geometry, bitmap layout, cursor hardware, font storage and file services constrain what the image can display and how it responds. Two correct VMs can preserve object-level meaning while producing different pauses, redraw speeds and device behavior.

Even characters exposed the compromise. Goldberg recalled that the cross-company effort forced standard ASCII because not every participant controlled its fonts. Portability expanded the set of machines that could join the system, but it narrowed one expressive surface to what the hosts could reliably share.

The Blue Book itself warned that then-current and near-future hardware could not supply all the power desired for Smalltalk's interactive goals. A VM contract could say what a send, return or object fetch meant. It could not make a weak processor feel like a Dorado, enlarge a display, standardize a mouse or eliminate every garbage-collection pause.

This is the durable engineering lesson: compatibility evidence must be read at the layer where it was collected. Passing an image or bytecode test is evidence about the image/VM agreement. It is not automatically evidence about timing, typography, windows, peripherals or the total user experience.

Publication was a three-part release

The public Smalltalk-80 release was deliberately larger than the Blue Book. The August 1981 special issue of BYTE supplied an early, approachable introduction. Goldberg and Robson's 1983 volume joined the language to the virtual-machine specification. A separate 1984 book, Smalltalk-80: The Interactive Programming Environment, documented how programmers actually worked inside the system. Glenn Krasner edited the volume in which implementers reported what they had learned.

Goldberg and Robson organized the language book together. In her oral history, Goldberg described a decision process in which she and Dan Ingalls would bring contested system questions to the group and make final calls, while Robson acted as an ombudsman for objections. Ingalls later recalled that Robson did most of the reference-interpreter work. The publication was thus both authored and governed: prose, executable model and group decision had to converge.

The split across books also acknowledged that no single artifact captured Smalltalk. Language semantics, VM machinery, interactive environment and implementation experience were connected but not interchangeable. The Blue Book specified the portable core. The environment book described a user-facing system whose quality still depended on a concrete host. The experience volume documented choices the formal interface intentionally left open.

The line runs through a team, not a single inventor

Any account centered on Goldberg needs to resist turning her into the sole source of Smalltalk. The Blue Book itself names Simula and Alan Kay's vision. Kay's historical account describes how Simula's objects and Sketchpad's interactive graphics shaped his thinking. Kay articulated the message-centered personal-computing direction. Dan Ingalls built and repeatedly evolved the interpreters and virtual-machine design.

Around them, a PARC team made the environment tangible. Diana Merry worked on text display and later demonstrated a galley editor mixing text and pictures. Ted Kaehler contributed early bitmap line drawing and later memory-system work. Larry Tesler worked on the Notetaker and the programming environment. David Robson helped turn system decisions into a rigorous book and reference interpreter. Bob Flegal worked with Goldberg on the book's artwork. Many others built browsers, editors, graphics, compilers, storage systems and release tools.

Goldberg's achievement is no smaller when placed in that lineage. She connected the research object to an external implementation community, negotiated permission to publish, designed a review in which hardware evidence could change the document, co-authored the specification and kept the release moving toward a finished public form. The outside port teams completed the loop by finding what an internal team could not see.

The contract survived by allowing different machinery

Later history clarifies why the boundary mattered. Ingalls records that some Smalltalk systems descended from licensed images while others were written from the documentation. At Apple, he adapted an APDA Smalltalk to different input and display conditions and found that a faster processor and larger screen transformed the experience even though the system's conceptual continuity remained.

Squeak offers a more decisive example. In the 1990s, Ingalls and colleagues used the published reference interpreter and an unrestricted APDA image to bootstrap a new implementation. The team then replaced the old object-table scheme with direct pointers, adopted generational garbage collection and generated C from a restricted Smalltalk subset. Ted Kaehler and Ingalls rebuilt the memory system; John Maloney wrote the translator; Scott Wallace reworked file access. The result was recognizably in the Smalltalk line without preserving the original host machinery.

That is what a productive portable contract does. It protects a useful seam, not every historical mechanism. It gives new implementers enough certainty to change what lies beneath the seam and enough evidence to determine when those changes have broken what lies above it.

The Computer History Museum's Smalltalk Zoo now makes this diversity visible across runnable preserved systems. A zoo is an apt metaphor: shared ancestry does not imply identical organisms. The Blue Book helped the family travel because it said which behaviors had to cross the border—and, just as importantly, which implementation choices could remain local.

Sources