Alan Kay Did Not Invent Objects

People keep claiming that modern OOP languages aren’t “really OOP” because they don’t follow Alan Kay’s definition of “OOP”. I can see the logic here, even if I disagree the conclusion. More recently I’ve seen people start claiming that Kay invented objects entirely. This is factually incorrect.

Alan Kay did not invent objects. They come from Simula, which the Smalltalk-72 manual cites as a major inspiration (pg 117). The famous 1981 Byte magazine issue that popularized Smalltalk and OOP explicitly says “the fundamental idea of objects, messages, and classes came from SIMULA.” It says that Simula allows users to create “object-oriented systems”, which is probably going to far but still. The Smalltalk team clearly knew about, and was inspired by, Simula’s object system.

Part of the reason this is such a persistent myth is because Kay himself said it in 1998:

Just a gentle reminder that I took some pains at the last OOPSLA to try to remind everyone that Smalltalk is not only NOT its syntax or the class library, it is not even about classes. 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.

And later follows that up in this interview:

I mean, I made up the term “objects.” Since we did objects first, there weren’t any objects to radicalize.

He later stopped claiming this but those other sources are still out there and still cited by people as fact.

Alan Kay coined the term “Object-Oriented Programming”

This is absolutely true.

OOP was about classes and objects

More recently people keep claiming that OOP “isn’t really” about classes and objects and the important bit is actually the messages. In the 1998 post, after saying how much he regrets “objects”, Kay also says that “the big idea is ‘messaging’”. He later follows up with:

OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I’m not aware of them.

Early OOP definitely considered messages important, but that primarily in the service of objects. Here’s how Dan Ingalls explains OOP in his introduction of Smalltalk-76:

The Smalltalk language is object oriented rather than function oriented, and this often confuses people with previous experience in computer science. For example, to evaluate <someobject>+4 means to present +4 as a message to the object. The fundamental difference is that the object is in control, not +. If <someobject> is the integer 3, then the result will be the integer 7. However, if <someobject> were the string 'Meta', the result might be Meta4. In this way, meaning rides with the objects of the system, and code remains an abstract form, merely directing the flow of communication.

In “Microelectronics and the Personal Computer” Kay talks about a “message-activity” system where “each activity belongs to a family” and talks about extending activities into “viewpoints” of object relationships as the future frontier. In the Smalltalk-72 manual he says (p. 18)

The central idea in writing Small talk programs, then, is to define classes which handle communication among objects in the created environment.

Looking at the early sources, everybody acts as if OOP consisted of three major ideas: classes that defined protocol and implementation, objects as instances of classes, and messages as the means of communication. The idea that classes and objects were secondary to the messages comes much later.

Smalltalk was the first true OOP language

The ACM gave a Turing award to Dahl and Nygaard and called them “co-inventors of OOP”. The Byte magazine similarly says Simula was object-oriented, and in “The Computer Revolution hasn’t happened yet” Kay calls Sketchpad “very object-oriented”. In my opinion, this doesn’t give Smalltalk enough credit. Unlike the other systems, in Smalltalk:

• There were no non-object primitives. Numbers were objects. Errors were objects. Classes were objects. Messages were objects.
• You could pass a message to any object, including other messages.
• Methods and implementations were associated with the objects, not the session.

The last one is the most subtle one and arguably the most important contribution, though nobody properly explains what makes it so special. In Simula, calling a missing method causes an error. This is part of the Simula spec. In Smalltalk-80, if no method matches the message, the object returns to the caller a doesNotUnderstand message by default. The calling object can choose to react to it, or just pass it along, or raise an error. A class can also override the default and do something besides return doesNotUnderstand.

It also means the messaging system is independent from the object internals. The two don’t even have to be part of the same project. This means that you can do things like send messages to objects written in different languages, transmit object definitions by mail, send messages via SMS, etc. In my opinion this is where a lot of the power of “message-passing” lies, but it’s also one of the least explored aspects.

Smalltalk had a surrounding context

People don’t invent tools in a vacuum. They have specific situations and problems and try to find solutions to those problems. Smalltalk’s innovations and OOP are no different.

Alan Kay was interested in personal computing. His work on FLEX, the Dynabook, and Smalltalk all revolve around that. In his vision, the PC would be a something totally under the user’s control, everything from core system logic to the graphic rendering tweakable and explorable at runtime. Message passing and late binding solve a lot of problems here. If a kid installs a new game, should they have to recompile the entire OS to use the new program? No: make it so that you can send any arbitrary message to any object and rely on runtime protocol-handling to fix it.¹ If a person clobbers the sound logic, should the whole OS crash? Of course not, so allow objects to decide how to handle messages themselves. This is a place where objects shine.

Ole-Johan Dahl and Kristen Nygaard were trying to solve a completely different problem. They were interested in simulation. One of the case studies in the Simula manual is modeling the spread of infection across a fixed population. The system is completely closed: you have a fixed set of code, you run your simulation, you get your output. For them, message passing isn’t useful. But things like being able to define simulations in terms of other simulations, specialize entities, and model time as a first-class object are incredibly useful. This is also a place where objects shine!

So who used objects “right”? That’s not a sensible question. They did different things because they had different problems. Our modern idea of OOP is a synthesis of all their ideas, as well as the ideas of Adele Goldberg, Barbara Liskov, David Parnas, Bertrand Meyer, Gul Agha, and many others. But none of them can lay claim to what OOP “really means”. Terms evolve as problems do.

tl;dr

Interviews done 30 years later are not good primary sources.