Didn’t Alan Kay coin the term “object oriented”?
He coined the term “object,” but what he meant by a computational object was different than what it came to mean: a data structure with associated operations upon it. Kay meant a parallel thread of execution which was generally sitting in a waiting state—one could make a very strong analogy between Smalltalk's vision of “objects” and what we call today “microservices,” albeit all living within the same programming language as an ecosystem rather than all being independent languages implementing some API.
But whether this is an “object-oriented” vision depends on whether you think that an object is intrinsically a data structure or an independent computer with its own memory speaking a common API. The most visible difference is that in the latter case one object mutating any other object's properties is evil—it is one computer secretly modifying another’s memory—whereas in the other case it is shrug-worthy. But arguably the bigger issue is philosophical.
That is hard to explain and so it might be best to have a specific example. So Smalltalk invents MVC and then you see endless reinventions that call themselves MVC in other languages. But most of these other adaptations of MVC have very object-oriented models: they describe some sort of data structure in some sort of data modeling language. But that is not the “object” understanding of a model in Smalltalk. When Smalltalk says “model” it means a computer which is maintaining two things: a current value of some data, and a list of subscribers to that value. Its API accepts requests to create/remove subscriptions, to modify the value, and to read the value. The modifications all send notifications to anyone who is subscribed to the value. There is not necessarily anything wrong with data-modeling the data, but it is not the central point of the model, which is the list of subscribers.
A more extreme example: no OOP system that I know of would do something as barbarous as to implement a function which would do the following:
> Search through memory for EVERY reference to that object, and replace it with a reference to this object.
That just sounds like the worst idea ever in OOP-land; my understanding of objects is as data structures which are probably holding some sort of meaningful data; how dare you steal my data structure and replace it with another. But Smalltalk has this; it is called Object.become. If you are thinking of objects as these microservicey things then yeah, of course I want to find out how some microservice is misbehaving and then build a microservice that doesn't misbehave that way and then eventually swap my new microservice in for the running one. (That also hints at the necessary architecture to do this without literally scanning memory: like a DNS lookup giving you the actual address, every reference to an object must be a double-star pointer under the hood.) And as a direct consequence, when you are running Smalltalk you can modify almost every single bit of functionality in any of the standard libraries to be whatever you need it to be, live, while the program is running. Indeed the attitude in Smalltalk is that you will not write it in some text editor, but in the living program itself: the program you are designing is running as you are writing it and you use this ability to swap out components to massage it into the program that you need it to become.
This is partly because the term at the time meant a patch of storage with multiple data fields -- like a punched card image in storage or a Sketchpad data-structure.
But my idea was about "things" that were like time-sharing processes, but for all entities. This was a simple idea that was catalyzed by seeing Sketchpad and Simula I in the same week in grad school.
The work we did at Parc after doing lots of software engineering to get everything to be "an object", was early, quite successful, and we called it "object-oriented programming".
I think this led to people in the 1980s wanting to be part of this in some way, and the term was applied in ways that weren't in my idea of "everything from software computers on a network intercommunicating by messages".
I don't think the term can be rescued at this point -- and I've quit using it to describe how we went about doing things.
It's worth trying to understand the difference between the idea, our pragmatic experiments on small machines at Xerox Parc, and what is called "OOP" today.
The simplest way to understand what we were driving at "way back then" was that we were trying to move from "programming" as it was thought of in the 60s -- where programs manipulated data structures -- to "growing systems" -- like Smalltalk and the Internet -- where the system would "stay alive" and help to move itself forward in time. (And so forth.)
The simplest way to think about this is that one way to characterize systems is that which is "made from intercommunicating dynamic modules". In order to make this work, one has to learn how to design and maintain systems ...
I was really not expecting you to join this conversation and I am very thankful to have crossed paths with you, even so briefly. Sorry for getting you wrong about the “objects” vs. “OOP” thing.
I have thought you could maybe call it “node-oriented” or “thread-oriented” but after reading this comment I think “ecosystem-oriented” might be more faithful a term?
https://www.quora.com/What-is-Alan-Kays-definition-of-Object...
P.S.: Thank you for all your contributions to our profession, and for your measured response to these kinds of discussions.
At Parc, I think we were able to make our point. Around 2014 or so we brought back to life the NoteTaker Smalltalk from 1978, and I used it to make my visual material for a tribute to Ted Nelson. See what you think. https://www.youtube.com/watch?v=AnrlSqtpOkw&t=135s
This system --including everything -- "OS", SDK, Media, GUI, Tools, and the content -- is about 10,000 lines of Smalltalk-78 code sitting on top of about 6K bytes of machine code (the latter was emulated to get the whole system going).
I think what happened is that the early styles of programming, especially "data structures, procedures, imperative munging, etc." were clung to, in part because this was what was taught, and the more design-intensive but also more compact styles developed at Parc seemed very foreign. So when C++, Java, etc. came along the old styles were retained, and classes were relegated to creating abstract data types with getters and setters that could be munged from the outside.
Note that this is also "simulation style programming" but simulating data structures is a very weak approach to design for power and scaling.
I think the idea that all entities could be protected processes (and protected in both directions) that could be used as communicating modules for building systems got both missed and rejected.
Of course, much more can and should be done today more than 40 years after Parc. Massive scaling of every kind of resource requires even stronger systems designs, especially with regard to how resources can be found and offered.
If you want verification, maybe you can convince him to do another AMA =) I’m still thinking about his more cryptic answers from the last one, which is well worth a read. I think that was before Dynamicland existed, but I may be off.
You are now making an affirmative assertion that Alan Kay did not coin the term. The burden of proof is on you, not him.
You make the claim he coined the term, the burden of proof is on you.
Until you do, it's perfectly reasonable and intellectually honest to reject that claim.
References I've seen have, of course, essentially all pointed back to Kay's claims. I imagine this is insufficient in your eyes, so I won't bother finding them for you.
Arguing "it's reasonable and intellectually honest to reject [the claim that Kay coined the term]" is silly. It's not reasonable, because there's no real reason to suspect the claim to be false in the first place. For 50+ years it has been accepted knowledge that Kay coined the term. Nobody — including people with direct experience on the same teams or with otherwise opposing claims — has stepped forward to dispute this fact in all that time. This would be just like saying "Well I don't think da Vinci really made the Mona Lisa. I mean, all we have is his word for it. Sure, the painting didn't exist before him, and its existence appears to have started with him, and people at the time attribute its existence to him, but for all we know maybe somebody else did it and gave it to him to use as his own!" Sure, it's possible... but it's a silly claim to make (and hence not reasonable).
Your position is not "intellectually honest" because it sincerely looks like you're just trying to be antagonistic. What's the point in arguing that Kay didn't coin the term? Do you have some unsung hero in mind you'd like to promote as the coiner? Or do you just like arguing against commonly-held beliefs for the sake of it? I don't see what you're trying to accomplish.
Two more thoughts:
1. The only way to prove Kay didn't originally coin the term would be to find hard evidence of it used in a similar fashion (i.e., with regard to programming) from prior to 1966 (the time Kay claims he invented the term).
2. If you had such evidence, you would need to prove that Kay had seen it prior to his alleged coinage. In the absence of such proof, the existence of the term prior to Kay's use would be irrelevant. Why? Because the community as a whole has gone off of Kay's claim for the whole time. If somebody else conceived of "object-oriented programming", we didn't get it from them — we got it from Kay.
I'm a little skeptical. That user certainly writes in a similar style to how I've seen Alan Kay write online, but I wouldn't be opposed to seeing some more proof. A one-day-old HN account claiming to belong to one of the most important people in CS from the past 50 years seems a little suspicious haha.
Also, I walk by your face a few times a week whenever I head into my lab. MEB has redecorated a few times over the years, but they always have a section of pictures of notable alumni and (of course) you're up there. Thanks for giving us a good name in the field and for all you've done!