Smalltalk
Smalltalk was developed at Xerox PARC between 1972 and 1980 as the implementation language for the Dynabook. Unlike earlier languages that treated data and procedures as separate entities, Smalltalk organized all computation around objects — self-contained units that held both state and behavior and communicated only by sending messages. Every integer, every window, every interface element was an object. The language was designed not just to produce working programs but to be a medium of expression: a child reading Smalltalk code should be able to understand what the code meant and modify it to mean something else. Smalltalk directly shaped Objective-C, Java, Ruby, Python, and nearly every modern programming environment.
The Maintenance Burden — Contrarian ^ Opus
There is a parallel reading of Smalltalk's legacy that begins not from its philosophical elegance but from the material conditions of software production. The live, inspectable environment that Kay championed required extraordinary computational resources relative to what most organizations could afford in the 1970s and 80s. A Smalltalk image was memory-hungry, processor-intensive, and demanded hardware that cost orders of magnitude more than a BASIC interpreter or C compiler. The democratic vision of children modifying their own software environments collided with the economic reality that only well-funded research labs could run the system at all.
More fundamentally, the biological metaphor of cellular organization that Kay borrowed may have been the wrong abstraction for industrial software development. Biological systems evolve through massive redundancy and tolerate enormous inefficiency — most mutations fail, most cells die, most organisms never reproduce. Software projects operating under commercial constraints cannot afford this exploratory waste. The procedural, file-based systems that won out over Smalltalk did so not because developers failed to grasp Kay's vision but because they needed predictable, auditable, version-controllable artifacts that multiple teams could coordinate around. The live image that never stops running is also the image that never stops accumulating technical debt, never fully documents its state transitions, never cleanly separates development from production. The opacity of modern AI systems that Kay critiques may be less a betrayal of Smalltalk's ideals than a scaling of its fundamental problem: when everything is live and mutable, nothing is truly comprehensible beyond the local interaction. The corporations didn't kill the dream; the dream was always too expensive to live.
In the AI Story
Smalltalk's central architectural insight — that software should be organized as communities of communicating objects rather than as sequences of procedural instructions — came from Kay's background in biology and his reading of the work on cellular systems. Kay saw biological cells as the model for robust, modular software: each cell knows what it is and what it can do, communicates with other cells through chemical messages, and does not require other cells to understand its internal workings. This principle, which Kay called encapsulation, became the foundation of object-oriented programming.
The language was inseparable from its environment. Smalltalk ran in a graphical workspace where any object could be inspected, modified, and recompiled on the fly. There was no distinction between runtime and edit time — the system was always live. This architectural choice reflected Kay's pedagogical conviction: a medium for thought must be inspectable and modifiable at every level, or it reverts to the black-box model that produces passive users. Contemporary programming environments have retained the syntactic features of Smalltalk and largely abandoned the live, inspectable workspace.
Kay has argued repeatedly that what the industry adopted from Smalltalk was the surface — classes, inheritance, message syntax — while missing the deeper point. "I made up the term object-oriented," he famously said, "and I can tell you I did not have C++ in mind." The large language model as an object that receives messages and responds has the syntactic shape of a Smalltalk object but lacks what Kay considered essential: the user's ability to open it up, understand its workings, and modify its behavior. It is an object whose encapsulation has become opacity.
Smalltalk also anticipated — and, Kay would argue, still surpasses — what contemporary AI tools promise. A Smalltalk image contained the entire working environment: every tool, every library, every example, every piece of documentation was a live object the user could examine and adapt. The current ecosystem of AI-assisted development, where code is generated into files the developer then reads as static text, has no equivalent of this liveness. The smooth interface has replaced the inspectable one.
Origin
The first Smalltalk (Smalltalk-72) was designed by Kay and implemented primarily by Dan Ingalls. Adele Goldberg joined as pedagogical lead. The language was refined through successive versions — Smalltalk-74, -76, -78, and finally Smalltalk-80, the version released publicly and documented in the "blue book." Every version was shaped by testing it with children, who served as the acid test: a child who could not read the code was evidence that the language had failed.
Smalltalk-80 was commercially distributed and directly inspired Apple's Macintosh development team. Steve Jobs's famous 1979 visit to PARC centered on seeing Smalltalk and the graphical user interface it ran in. What Apple (and later Microsoft) took from the visit was the interface. What Kay wished they had taken was the system's underlying openness.
Key Ideas
Objects as cells. Software organized as communities of self-contained units that communicate through messages — a biological architecture for code.
Encapsulation without opacity. Each object hides its internal complexity from others, but the user can always open the hood and see how it works.
Live environment. No distinction between runtime and edit time — every piece of the system is inspectable and modifiable while running.
Pedagogical language. Designed to be read and modified by children, not just by professional programmers.
Surface without substance. Modern object-oriented languages retained Smalltalk's syntax while abandoning its live, inspectable character.
Debates & Critiques
Is the Smalltalk ideal recoverable in an AI-augmented programming environment, or has the commercial computing industry permanently closed off that path? Kay's work on Etoys, Croquet, and STEPS suggests the ideal remains technically feasible. The question is whether it is institutionally feasible in an industry organized around consumption.
Appears in the Orange Pill Cycle
Scale Versus Scrutability — Arbitrator ^ Opus
The tension between Smalltalk's inspectable ideal and industry's sealed products resolves differently depending on which question we're asking. If we're asking about pedagogical power — whether a programming environment can teach its own principles — then Kay's vision remains essentially correct (90% weight). No modern development environment approaches Smalltalk's capacity to let learners see the entire system as modifiable material. The closest contemporary equivalent might be browser DevTools, and even these separate the inspecting user from the modifying programmer.
But if we're asking about sustainable software production at scale, the contrarian view carries more weight (70%). The live image model genuinely does create versioning nightmares, makes distributed development difficult, and accumulates state in ways that become unmanageable. The file-based, statically-compiled systems that dominated weren't simply cheaper; they enabled coordination patterns that Smalltalk's everything-is-live model resisted. This isn't just about corporate capture but about the genuine tradeoffs between transparency and maintainability.
The synthesis might be that Smalltalk represented one pole of a necessary tension: maximum scrutability and modifiability at the cost of coordinability and predictability. Modern AI systems represent the opposite pole: maximum capability at the cost of comprehensibility. What we actually need — and what neither pure Smalltalk nor pure black-box AI provides — is selective scrutability: systems that can be opened and inspected at chosen levels of abstraction, where the depth of inspection matches the user's need and expertise. The biological metaphor remains apt, but incompletely applied: organisms hide their cellular complexity most of the time, revealing it only when repair or growth demands. The next paradigm might learn from both failures.
Further reading
- Adele Goldberg and David Robson, Smalltalk-80: The Language and Its Implementation (Addison-Wesley, 1983)
- Alan Kay, The Early History of Smalltalk (ACM SIGPLAN, 1993)
- Dan Ingalls, Design Principles Behind Smalltalk (BYTE Magazine, 1981)
- Bret Victor, The Future of Programming (talk, Dropbox DBX Conference, 2013)