Why Smalltalk Didn't Win

Six chapters have made a consistent case: Smalltalk was first, philosophically coherent, and directly responsible for ideas — message passing, MVC, the live environment — that shaped decades of software that came after it. So the obvious question, asked directly and honestly in this chapter: why isn't it the dominant language today? Why do languages that borrowed only part of its ideas win out commercially, while the original lost mainstream relevance?

Commercial and Licensing Factors

Smalltalk-80 was commercialized through a specific, restrictive early licensing model — Xerox licensed it to a small number of vendors, including ParcPlace Systems, itself spun out specifically to commercialize Smalltalk. This happened at a time when competing languages, C and later C++, were comparatively cheap or free and widely available across virtually every platform. Cost and availability mattered enormously to who actually adopted a language at scale — a real, concrete, entirely non-philosophical factor.

Smalltalk environments were also historically demanding of hardware resources — the full live image, the GUI environment, all running together — at a time when hardware itself was expensive and limited. A real, practical adoption barrier, separate from any of the language's own philosophical merits.

C++ and Java — OOP Bolted Onto Familiar Syntax

C++ (Bjarne Stroustrup, early 1980s) took a genuinely different strategy: rather than building OOP as a from-scratch, radical new environment, it added class-based OOP features directly onto C. Existing C programmers, and the enormous existing base of C code, tooling, and compilers, could adopt OOP incrementally — without learning an entirely new paradigm, environment, and syntax all at once. This lowered the adoption barrier dramatically compared to Smalltalk's own "learn a completely new environment" cost.

Java (1995) went further in some ways — garbage collection, a more disciplined object model — but still kept C-family syntax: curly braces, semicolons, familiar control flow, explicitly designed to feel approachable to the enormous existing population of C/C++ programmers, per java1-1's own material on that exact syntax choice. Sun's own marketing, its "write once, run anywhere" platform strategy, and a genuinely different, more open licensing and distribution approach than Xerox's own Smalltalk model all mattered enormously here too — a real business-strategy contrast, not just a technical one.

The throughline: familiarity and incremental adoption cost, not technical or philosophical superiority, is what won. A language that let programmers keep 90% of what they already knew while gaining OOP incrementally beat a language that asked them to learn an entirely new environment and philosophy from scratch — even though the from-scratch language was arguably more coherent and consistent.

The Image-Based Model's Real Friction

This directly delivers on the honest preview from smalltalk1-4: version control. git1's own file-based diff/commit model — and every version control system before Git, CVS and Subversion included — fundamentally assumes the artifact under version control is a set of discrete, diffable text files. A live Smalltalk image doesn't decompose into that shape naturally. Tools were built over the years to extract text-based representations of image state specifically to work around this — change sets, "fileOut" mechanisms — but these were always somewhat bolted-on workarounds, unlike a C, Java, or Rust codebase, which simply is files from the start.

This mattered enormously as software development matured into a genuinely team-based, collaborative discipline through the 1990s and 2000s. The entire ecosystem of code review, diffing, CI/CD (pipelines1's own material), and distributed team collaboration assumes files-on-disk as the fundamental unit — and Smalltalk's own image-first model was structurally a worse fit for that emerging ecosystem, regardless of its own philosophical elegance.

Deployment and Distribution

A related, concrete point: shipping a compiled C, C++, or Java program to a customer is straightforward — a binary, or a JAR, self-contained and relatively predictable. Shipping "a snapshot of an entire live image" as a deployable product was a genuinely harder, less standard problem historically — the image contains far more than just the application itself, including development tools, debugging infrastructure, and potentially unrelated experimental code left in the live system. Extracting a clean, minimal, deployable subset was its own real engineering problem Smalltalk vendors had to solve — one C and Java's own compile-to-a-single-artifact model never faced in the first place.

An Honest Synthesis — Not a Story of Technical Failure

Worth restating directly, since a chapter like this can easily imply otherwise: none of the above means Smalltalk was technically inferior, or that its ideas were wrong. smalltalk1-3 through smalltalk1-6 already demonstrated the opposite — its ideas were coherent, genuinely influential, and in many ways more elegant than what replaced it commercially.

Reflection Questions