Lesson 10: The Vision That Mainstream OOP Left Behind
Alan Kay has said, more than once, that most of what gets called "object-oriented programming" today isn't what he meant. The term is his, but the thing it describes — classes, inheritance hierarchies, method calls — is something closer to the opposite of his original idea.
That gap is worth sitting with. Because the vision Smalltalk was built to express is, I'd argue, more legible now than it was in 1980. Not because the world caught up to Smalltalk, but because we've lived long enough with what replaced it to feel what's missing.
What Kay Actually Meant by "Object"
The confusion starts with a word. When most programmers hear "object," they think: data bundled with methods. A BankAccount that knows how to deposit(). A User that can resetPassword(). That's the mainstream inheritance.
But Kay's definition was something else entirely: "Object-oriented programming to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things."
Notice what's absent: classes, inheritance, type hierarchies. The center of gravity isn't structure — it's communication. Objects are autonomous agents that send messages to each other. They don't call functions; they make requests and decide independently how to respond. The receiver, not the sender, determines what happens.
This is a philosophical difference, not a syntactic one. In the mainstream OOP that Java and C++ popularized, you design a taxonomy first — a hierarchy of types — and then populate it with instances. In Kay's vision, you design a society of communicating agents. The structure emerges from the messages, not the other way around.
Why the 1980s Couldn't Hold the Idea
Smalltalk was created at Xerox PARC by Kay, Dan Ingalls, Adele Goldberg, and others during the 1970s, with the first general release as Smalltalk-80. The environment was remarkable: a live, reflective system where you could inspect and modify running objects, where the IDE and the language were the same thing, where the boundary between "program" and "programming environment" dissolved.
The hardware of the era couldn't sustain that vision at scale. As one retrospective on Objective-C's origins put it: Smalltalk "requires a fairly large VM to run" and created a world where "you don't program your computer with LISP or Smalltalk — your computer runs a separate LISP or Smalltalk computer." The isolation was the problem. Smalltalk's richness came at the cost of being its own sealed universe.
So when object-orientation spread into systems programming through C++ and later Java, it kept the vocabulary — objects, methods, encapsulation — and dropped the philosophy. Late binding became a performance concern to minimize. Reflection became a debugging tool, not a design principle. The live, malleable environment became a compile-edit-run cycle.
The mainstream got the nouns. It left behind the verbs.
Why the Vision Reads Differently Now
Here's what's changed: we now build systems that look a lot like what Kay was describing, just without the language to match.
Microservices are autonomous agents that communicate by passing messages. They hide internal state. They respond to requests in their own way, regardless of what the caller expects. The caller doesn't know — and shouldn't know — how the receiver is implemented. That's late binding at the architectural level.
Actor-based systems like Erlang's OTP model, which we've touched on in earlier issues, are even closer: isolated processes, message passing, no shared state. The philosophy Kay articulated for objects, Erlang implemented for processes.
And the current wave of agent-based AI systems — where autonomous components negotiate, delegate, and respond to requests — maps almost directly onto the Smalltalk mental model. Not because anyone copied Kay, but because the problem of coordinating independent, stateful agents keeps reasserting itself, and his framing turns out to be a useful one.
I'd argue the reason Smalltalk's vision feels more relevant now isn't that we've gotten smarter. It's that we've built systems complex enough to rediscover the problems it was designed to solve.
The Lesson for Your Practice
The concrete takeaway here isn't "use Smalltalk." It's a diagnostic question you can apply to any system you're designing: am I building a taxonomy, or am I building a society?
Taxonomy thinking asks: what is this thing? What type does it belong to? What does it inherit? Society thinking asks: what messages does this component send and receive? What does it need to know about its neighbors — and what should it be allowed to ignore?
Most systems benefit from both. But when a codebase starts feeling rigid — when adding a feature requires touching six layers of inheritance, when a change in one place ripples unpredictably — that's usually a sign that taxonomy thinking colonized territory that society thinking should have claimed.
Your next action: Pick one class or module in a current project and ask: does this thing belong to a type, or does it respond to messages? If the answer is the latter, notice whether the design reflects that. Often it doesn't — and that gap is where the rigidity lives.