The Image — A Live, Persistent System

smalltalk1-3 covered the philosophy — everything is an object, everything is a message. This chapter covers the environment that philosophy actually lives inside, and it's just as unfamiliar to a modern programmer as the message-passing model itself: the Smalltalk "image."

Source Files Are Not the Program — The Image Is

In virtually every language on this site, "the program" is fundamentally a set of source files, compiled or interpreted fresh each run, producing a new process from scratch every single time — c1-1's own compile-then-link model, rust1-1's own cargo build, py1-1's own script execution. The running process's own state disappears the instant it exits; the next run starts over from source, with nothing carried forward.

Smalltalk inverts this entirely. The "image" is a literal, saveable snapshot of an entire live system's objects and state — every class, every object instance, every open window, potentially even a half-finished thought mid-edit — all preserved together in one file. You don't "run the Smalltalk program" the way you run a compiled C binary. You load the image, and you're dropped directly back into the exact live system state you left it in.

What This Actually Means in Practice

There is no meaningful "compile, then run" distinction the way c1-1/rust1-1 established. Changes made to a class apply to the live, running system immediately, while it's executing, with nothing restarted. Objects already running continue running — and, worth naming honestly, can genuinely continue using the old version of a method until something tells them to pick up the new one, meaning a class's own definition and an instance's own currently-running behavior can actually diverge mid-session. Powerful, but a real, documented source of confusion.

This is exactly why Smalltalk programmers didn't typically edit text files in an external editor the way C, Rust, or Python programmers do — the natural way to work is inside the live image itself.

The Class Browser — Live Editing, Not File Editing

The class browser is Smalltalk's own primary development tool. Rather than opening a .java or .rs file in a text editor, a Smalltalk programmer navigates a live, structured view of the actual class hierarchy currently loaded in the running image — browsing packages, classes, and individual methods directly as live objects, editing one method at a time, taking effect immediately upon being accepted. No separate save-then-compile-then-run steps exist at all.

This is a genuinely different mental model from code1's own VS Code Essentials course — however powerful VS Code's own live debugging and hot-reload features are, they still fundamentally operate on files sitting in a folder on disk, edited by a general-purpose text editor. Smalltalk's class browser only makes sense because there are no files in the conventional sense to begin with — the "source" is a live structure inside the image itself.

Contrasted With the Edit-Compile-Run Cycle

Worth being precise here: a Python REPL (py1-1) and a Smalltalk image are not the same thing, even though both let you type expressions and see live results. A Python REPL session's own state disappears the moment the terminal closes, with no built-in mechanism to save "the whole running interpreter state" back to disk and reload it exactly as it was. A Smalltalk image genuinely can do exactly that — as a first-class, designed feature of the system, not an ad-hoc workaround.

Why This Serves Kay's Original Vision

This ties directly back to smalltalk1-2's own Dynabook material: a live, directly-manipulable, always-running environment is exactly what a child exploring and building things needs — no gap between poking at the system to see what happens and actually programming it. The image is the environment being explored, not a separate artifact produced by a separate build process standing between the person and the system.

Reflection Questions