Erlang/Elixir are two of the least OO languages I can think of. Point still taken though. Elixir is an absolute joy, and the more new languages take examples from it, the better.
Edited to add: Kay also frequently says he's a proponent of object oriented, not class oriented programming. Classes are just a means of organizing the code, objects and their relationships is what matters. In that way, modules in Elixir are not inferior to classes in single-inheritance OO languages: they offer the same level of sharing and composing code (via macros, defoverridable, and defdelegate). Add to it protocols, which can extend arbitrary types (modules) and you get quite nice OO toolbox to use in Elixir.
One source: https://hillelwayne.com/post/alan-kay/
As that article clearly shows, at least once you’re past its clickbait title, Kay acknowledges his influences. That isn’t a lack of clarity, it’s an awareness that we all build on the effort of our peers and predecessors, that ideas do not spring forth fully formed from the void.
This does not discredit anyone’s work, far from it; context is an aid to understanding.
What I mean by lack of clarity is that Kay in 1998 thinks that messaging is the key idea, and suggests that was always the key idea. But none of the historical sources I've seen suggest he was clearly and consistently saying that in the 70s.
That's really a minor point, it does nothing to invalidate Kay's contributions. You can design a system that has value, and only later find the best way to talk about its value. That happens constantly: people create something and then end up saying "in hindsight, I got X right and Y wrong" or "back then, I knew this worked, but it was only later that I knew why".
It doesn't disprove the idea that focusing on messaging gives you the best version of OOP. It doesn't even disprove that "real" OOP is about messaging (though I think that argument has a high bar to clear--most terms are messy).
What it does disprove is that messaging has a right to be the core of OOP because Alan Kay defined it that way back in the 70s.
P.S. Maybe the title isn't ideal, but Hillel was literally reacting to someone who said Alan Kay invented objects: https://lobste.rs/s/8yohqt/alan_kay_oo_programming#c_5xo7on. Actually, that might be a better source than what I linked to, because it marshals more evidence that Kay was not consistently saying "messaging is what matters" during the 70s. He may have believed it, he may have said it sometimes, but he wasn't consistent about it.
Again, that's not a criticism of Kay, except the super mild one that his 90s/2000s memory of what he said 20 years earlier wasn't perfect. But I forget shit I said last week, so I'm not gonna judge.
Well, I think "messaging" is an abstract concept. It doesn't have rights, so there was nothing to prove.
Nevertheless, credit matters, because people matter, and do have rights. One of those rights is to have an opinion, including the opinion that messaging is the core of OOP.
> clearly and consistently saying that in the 70s
This is indeed a preposterous and unhealthy standard to expect of anyone, on any topic. It's the kind of thing that two-bit politicians like to dig up on each other, to nobody's edification.
We agree. No idea how I screwed up that sentence. The intent was "that messaging is the right core of OOP because", but it was awkward, and I spliced something together.
> It's the kind of thing that two-bit politicians like to dig up on each other, to nobody's edification.
This is a discussion of what a word means, not an attack on someone's character.
Still, the definition Kay gave as late as in 1998 resonates with me the most:
OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.
And this is almost exactly what Erlang implements: just add "asynchronous" before "messaging" and it fits perfectly.
you can find his various comments here: https://news.ycombinator.com/threads?id=alankay
- Main abstraction are classes (of objects).
- Concept of self-initializing data/procedure objects Internal ("concrete") view of an object vs an external ("abstract")
- Differentiated between object instances and the class
- Class/subclass facility made it possible to define generalized object classes, which could be specialized by defining subclasses containing additional declared properties
- Different subclasses could contain different virtual procedure declarations
- Domain specific language dialects
Big if there. Most people do not mean Kays OO when they say OO.
There's (at least) a third model IMO from CLOS & friends, such as Dylan, S4, and I'd argue Haskell Typeclasses. Not sure what I'd call it but it's the idea where you define data classes, generic functions, and then provide linkages between those data classes and the generic functions to give you methods on the state
Actually, if not for some historical accidents, we could have Dylan in place of Java today... I sometimes dream about such a world: functional core, CLOS-like generic functions and multimethods, sane multiple inheritance, syntax-case-like macros, native AOT compiler, sane module system... OpenDylan - the implementation I played with - is slow as molasses, but with even a tiny fraction of the work put into Java it could be made fast enough to rival C++. It's one of the most striking wasted chances in the history of programming.
An example would be non-fragile ABIs (ObjC has this, C++ doesn't) or typestate/built in state machines (so you can't call methods if the object is in an invalid state for them). There's encapsulation at least, it's a start.
Fragile ABI is basically a C++ problem. Java has had a stable OO ABI for 25 years now. The .NET ABI has gone through a few iterations, but is stable now. Of course Microsoft also had COM, which is/was a stable OO ABI accessible to many languages including C++ and was arguably just a subset of the C++ ABI without templates.
In the AOT compiled work Swift now has a stable OO ABI (sort of). Rust is interested in getting one. Lack of a stable ABI is not an OO problem but more a problem of languages that are designed to compile ahead of time to native code and use native formats as their primary artifact format.
Most features OO has reduce complexity and bugs, that's why people use them. There's no comparison between a clean OO API and the de-facto standard state before that, e.g. POSIX, Win32, Carbon.
C++ is more of a multi paradigm language where the designers (eg Alexandrescu) actually publish books telling you to focus on algorithms and generic programming rather than object trees. KDE/Qt reinvent messaging on top of the default OO, don’t they? There’s something about slots.
> There's no comparison between a clean OO API and the de-facto standard state before that, e.g. POSIX, Win32, Carbon.
Don’t know about Windows but POSIX and Carbon were as OO as they needed to be - a function where the first parameter is a “file” or “context” is being object oriented. There were actually several attempts to replace Carbon with more OO APIs, that used heavy implementation inheritance, like Taligent and MacApp and they failed because they were too complicated. Cocoa succeeded by using messaging and composition instead like Alan Kay wanted.
Don’t know about Windows but POSIX and Carbon were as OO as they needed to be - a function where the first parameter is a “file” or “context” is being object oriented.
Honestly I don't know of anyone, including the people who defined those APIs, who would call them object oriented. POSIX functions aren't even namespaced and routinely don't even take a struct as the first parameter. Implicit state is everywhere in POSIX, Win32 and I think also Carbon.
Cocoa succeeded by using messaging and composition instead like Alan Kay wanted.
Cocoa "succeeded" by being the official API of the first non-failed attempt at resurrecting macOS. On Windows, the API that "succeeded" was .NET which is a classical C++ type of OO. In practice, Objective-C caused a lot of problems for Apple. They would have junked it years earlier but Steve Jobs was wedded to it and couldn't understand why anyone wanted anything else. The moment Jobs died Swift was started as a project, and Swift does not have objc_msgSend at its centre, at least not if I understood the Swift ABI correctly.
The "messaging" concept caused problems in the following ways:
* Performance, despite objc message sending being heavily optimised.
* Bizarre semantics that led directly to horrible bugs, like sending a message to null being "valid" but returning junk if the return value was meant to be a struct.
* Difficult to optimise due to the dynamic language features, which are nonetheless hardly used (e.g. ability to redefine methods on the fly).
The latter problem is shared with languages like Ruby.
Why the past tense, when COM is the main way Windows APIs have been introduced since Windows Vista, as COM took over Longhorn OO ABI ideas?
Nowadays we just call it WinRT.
I haven't kept up much with Windows programming so lost track at some point of what their current-gen tech is and how it works. WinRT isn't just COM is it. It's custom languages, new app metadata formats and stuff. I don't see IUnknown in any modern Windows code samples.
I would suggest that if you asked people to define the term, Kay’s definition would likely be the single most common (even after normalizing variations in wording).
It would still only be a plurality, sure, but the remaining majority doesn't share a common understanding, either.