Good article developing the Ideas of Alan Key and what he meant about OOP:
“OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.”
~ Alan Kay
I feel like indirectly I already learned a lot of what this article teaches just for paying attention to the Clojure Culture.
Medium is paywalled now it seems?
At this point I feel like it be better he told us what he doesn’t think OOP means? I guess he’s only excluding inheritance? But how does he envision the late binding to work if so?
And when he says messaging, what does that mean? No reference passing? All data passed as values? No shared memory anywhere?
This talks a bit about how unclear he’s definition is: https://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented
From that read, it sounds like he’d maybe consider only languages with late binding everywhere to qualify as OOP, thus C++ and Java are out, C++ because it needs explicit virtual declarations to be late binded, and Java because it only does late binding on the type of the first argument.
I believe Simula created the object model no? And this was your typical class based with inheritance virtual method call model. And then Smalltalk 71 and 72 were more inspired by the Actor model, at which point they weren’t coined ObjectOriented, until Smalltalk 80 came around, but this one was no longer based on the Actor Model, but back to what Simula had started, and that’s the first Smalltalk to be considered ObjectOriented.
Someone who’se lived through and has used these please chime in.
At this point, I believe Smalltalk is also your typical Class based with inheritance OOP language.
So does Alan Kay not believe that Smalltalk did OOP right? Is he referring back to the Actor Model and what Smalltalk 71 and 72 were doing?
Also, “message passing” versus “function call” has always been a confusion of mine. Some people say messages differ in that you can’t pass a register or memory pointer, thus all input is copied and passed by value. But not all places define it as such. Some people seem to say the historical idea of “message passing” was basically just late binding. It contrasts itself with just static function calls.
And from what I gather, the term was coined to imply that instead of calling a function, you ask a process (a noun) to perform some action based on your message. Thus “message passing” would basically mean that behavior is invoked by first choosing the noun and then the message. So that plays well into OOP as the Object is the process and the method is the message you pass the process. After that, it’s up to the process machinery (Object on this case) to figure out what to do based on the message, and the caller just trusts the process to do the right thing.
Anyways, I find this stuff fascinating, but there’s so much overloaded definitions for such terms, it’s hard to really figure out. And often, they are vague ideas, and once you get into a specific concrete programming language, things start to differ or details of two languages trying to provide the same idea ends up being very different in practice.
For me, one of the key things that Smalltalk supported – later supported by Ruby and ColdFusion (and probably others) – was that if you “passed a message” that an object did not understand, it could handle it through a “does not understand” catch-all handler (in Ruby/ColdFusion it’s “missing method”).
In addition, you could add new handlers to an object at runtime, allowing it to understand additional messages (metaprogramming in Ruby/ColdFusion).
So, you could have objects that handled messages in a completely dynamic way, with their behaviors changing at runtime, as needed.
Smalltalk is how I originally learned OOP (before I became a C++ programmer and then a Java programmer) so it was very nice to see that functionality reappear in Ruby (although I dislike Ruby’s syntax intensely) and also in ColdFusion (which has a much more JS-like syntax).
Recall also that Smalltalk had a context, or a world, that included the IDE, and it was primarily driven by interacting with visual components in that world to which you would add methods (more like event handlers) while the whole thing was already running. I think this is a missing piece in properly understanding the context of his comments since most of us have only ever experienced coding in a text editor.
I don’t think Kay had the Actor model in mind, at least I’ve never heard him acknowledge that as a direct influence, though there exist a number of similarities. He instead claims inspiration from biology. Erlang started as an implementation of Smalltalk ideas and adopted the Actor model as they moved forward. Is that what you are thinking of, perhaps?
In the link I shared it says:
I’m not sure how accurate that is, but I tend to trust C2 wiki. It also explains my confusion with the OOP idea of “message passing”.
Interesting! I shall have to read further!
To be fair, Smalltalk’s IDE was a set of small text editors, effectively, that let you modify the code live in the running system – and Clojure with a REPL attached to an editor comes about as close to that of any language I’ve used in 30 years.
But I also think that unless your way of working with Clojure is entirely REPL-driven, and you never type into a REPL – you only ever evaluate forms from your editor, you’re not going to come close to way Smalltalk environments allowed.
Peripheral to the discussion so far, but given that this is a Clojure forum, it’s a little bit interesting that Scheme, one of Clojure’s most obvious ancestors, was
(From the Scheme Wikipedia page.)
" Is he referring back to the Actor Model and what Smalltalk 71 and 72 were doing?"
I’ve seen him basically say that, yes. That 71 was the purer implementation of what OO should be like, and that later Smalltalks made compromises to be tractable on the hardware they were using.
He seems to approve of Erlang too.
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.