Smalltalk and the Big Idea of Messaging
We remember Smalltalk as the birthplace of object-oriented programming. Alan Kay says we remembered the wrong half.
Ask a working programmer what object-oriented programming is and you'll hear about classes, inheritance, encapsulation, maybe polymorphism. Ask Alan Kay — who coined the term — and you'll get something stranger, narrower, and more interesting. You might also get an apology.
I'm sorry that I long ago coined the term "objects" for this topic because it gets many people to focus on the lesser idea. The big idea is "messaging."
To understand what Kay means is to recover a road computing mostly didn't take.
Objects as little computers#
Kay's mental model for an object did not come from data structures. It came from two places: biological cells, and the early ARPANET. A living cell is a tiny, autonomous machine. It guards its internal chemistry behind a membrane and interacts with the rest of the body only by exchanging chemical signals. A computer on a network is similar: a self-contained system that hides its internals and communicates only by sending and receiving messages.
So Kay imagined a program not as data plus procedures, but as a society of objects, each one a little computer in its own right: it has its own private state, it protects that state absolutely, and it does only one thing in public — it sends and receives messages. You never reach inside an object. You ask it, by message, to do something, and it decides how to respond.
This is object-oriented programming in its original sense, and notice what isn't in it. There's no mention of classes or inheritance. Those came along as a way to organize and build objects, and they're useful, but for Kay they were never the point. The point was autonomy and messaging.
Why messaging is the big idea#
If the difference sounds academic, here's why Kay thinks it's the whole game.
When one object talks to another only by message, the sender doesn't — and can't — know how the receiver will handle it. It can't reach in and depend on the receiver's internals, because there's no "in" to reach. All it has is the message. That means the receiver is free to be anything at all, as long as it responds to the message sensibly. You can swap one object for a completely different one, written years later, in a different style, and nothing breaks — because nothing depended on anything but the message.
This is what makes a system grow and change the way living things do. Kay's recurring example is the internet: it has run continuously for decades, scaled by many orders of magnitude, and replaced essentially all of its hardware and most of its software — without ever being stopped. It can do that because its parts are autonomous and communicate only by messages over agreed protocols. No part depends on the guts of another. Kay wanted programs to have that property: to be more like the internet and less like a single brittle machine. Messaging, plus extreme late binding, is how you get it.
The live world#
Smalltalk didn't stop at a language design; it was an entire environment, and the environment embodied the same philosophy. You worked inside a living image — a persistent world of objects, all alive at once. You didn't write a program, compile it, and run it. You reached into the running world, changed a method, and watched the change take effect immediately on the objects in front of you. The system was always on, always inspectable, always editable. There was no wall between writing the program and using it.
To build this, the PARC team had to invent much of the modern interface — overlapping windows, the mouse-driven GUI, the class browser — because you can't sculpt a live world of objects through a teletype. The interface and the language were one idea: a medium you author in, dynamically, while it runs. That idea served the larger goal of the Dynabook.
What we kept and what we lost#
Smalltalk's ideas spread, but selectively, and the selection is telling. The industry took the syntax of objects — classes, inheritance, methods — and built C++, Java, C#, and the rest. It mostly left behind the spirit: the autonomy, the messaging-first mindset, the live malleable environment, the late binding of everything.
Kay has said, only half joking, that he didn't have languages like C++ and Java in mind when he invented the term, and that by his definition most "object-oriented" languages aren't. The mainstream kept objects as a way to package code and lost objects as a way to think about systems as societies of communicating, independent agents.
Why? Part of the answer is worse is better: the cruder, more static, more machine-friendly designs were easier to implement and to optimize, and so they won and then improved, while the more elegant and dynamic vision stayed in the lab. Part is simply that messaging-first design is hard — it asks you to give up the comfort of reaching into other parts of your program, and to design protocols instead of poking at state.
But the road is still there. Every time you draw a clean boundary between components and let them talk only through a well-defined interface; every time you choose a message over a shared variable; every time you build something that can be changed while it runs — you're walking a little way down it. The big idea is messaging. It's still a good one.