Smalltalk is an object *system*, rather than a language.

The syntax of Smalltalk famously fits on a postcard, but understanding it takes at least a few minutes.

The entire system, including its development tools and application code is stored in a snapshot file, which is essentially a memory dump of the entire heap. (Two Decades of Smalltalk VM Development, p. 58–59)

> When programming with Smalltalk, the programmer usually starts from a snapshot which contains the core libraries, the development environment and the application under development. More precisely, the snapshot includes objects (such as the classes), the compiled methods in the form of bytecodes and the running processes. Developing applications consists essentially in writing and editing code, which installs, modifies and removes classes and compiled methods to and from the class hierarchy. Programming may be done live, as the application under development is running. For example, objects may have their shape changed on the fly as instance variables are added and removed. A new snapshot can be made during or at the end of the development session.

Snapshots can also be used to avoid long start-up times when fixing specific bugs. The VM can be run to a point where the bug is about to manifest and a snapshot taken. Then multiple analyses of the bug can be undertaken by loading the snapshot and resuming execution, either in the normal VM or in the simulator, short cutting the time to reach the bug.


Design Principles Behind Smalltalk. Daniel H. H. Ingalls. Learning Research Group. Xerox Palo Alto Research Center. BYTE Magazine, August 1981


The purpose of the Smalltalk project is to provide computer support for the creative spirit in everyone. Our work flows from a vision that includes a creative individual and the best computing hardware available.

We have chosen to concentrate on two principle areas of research: a language of description (programming language) that serves as an interface between the models in the human mind and those in computing hardware, and a language of interaction (user interface) that matches the human communication system to that of the computer.

Our work has followed a two- to four-year cycle that can be seen to parallel the scientific method:

Build an application program within the current system (make an observation)

Based on that experience, redesign the language (formulate a theory)

Build a new system based on the new design (make a prediction that can be tested)

The Smalltalk-80 system marks our fifth time through this cycle. I'll start with a principle that is more social than technical and that is largely responsible for the particular bias of the Smalltalk project:

Personal Mastery: If a system is to serve the creative spirit, it must be entirely comprehensible to a single individual.


The article goes on to mention a dozen more principles that were equally unexpected by the Byte Magazine hobbyist readership. Personal mastery is the perfect companion to the personal computer which completes a vision that Byte documented.

Smalltalk has floundered after several decades of interest. It was only available to people who could justify paying money to express their creative spirit. Later it became clear that it would not recover because a growing internet was less concerned with power to individuals.

Ward learned Smalltalk after having dug deeply into Lisp in the course of studying VLSI tooling: > I read the self-hosted reference implementation and was impressed with how much innovative tooling could be built within the 32 thousand objects available in its 15-bit address space. Allen Wirfs-Brock explained how he took efficiency shortcuts while preserving the semantic ideal.