3 ms·

How, in your opinion, does “mainstream” OOP differ from what Smalltalk OOP was/is? I tell people Alan Kay’s 97 OOPSLA keynote “I invented the term object orien

How, in your opinion, does “mainstream” OOP differ from what Smalltalk OOP was/is? I tell people Alan Kay’s 97 OOPSLA keynote “I invented the term object oriented, and this is not what I had in mind”, but I find it difficult to articulate to people who are doing “mainstream” OOP, what they’re missing. It’s like trying to explain the taste of salt. Just curious if you have any better way of explaining it. Oddly, I’ve been learning Elixir/Erlang for the last year, and though it’s definitely not OOP, there’s something oddly resonant about it with my Smalltalk past from 10 years ago.

danuker 5y ago
> Alan Kay’s 97 OOPSLA keynote Is it this one? https://www.youtube.com/watch?v=oKg1hTOQXoY https://www.youtube.com/watch?v=oKg1hTOQXoY Edit: I suspect it is this one, at 10:33 Alan says "Actually I made up the term <<object-oriented>>, and I can tell you I did not have C++ in mind."
- ncmncm 5y ago
  Alan Kay has been redefining what he calls OO for decades. He has lost all credibility. He cribbed OO for Smalltalk from Simula, same as Stroustrup did for C++. (Smalltalk-72 was not OO.) "OO" is just a name for something that already existed. Anyway there is nothing very meritorious about OO: it is sometimes the right thing for part of a problem. But organizing a whole language around it is as idiotic as organizing a car design around making left turns.
barrkel 5y ago
Agents with explicit messages are much closer to Smalltalk OO than virtual methods implemented via dispatch tables, with statically typed arguments. OOP has its place. I think it's decent in the small - when you're dealing with data structures which inherently have state and need to maintain invariants - and it's decent, in the agent form, in the large, where you have encapsulated state in separate agents which communicate with one another using messages, as long as you have other actor-model things like fault tolerance. It's in the middle, when you're trying to write a big app filled with communicating mutable objects with lots of mutual references, that things can get pretty sticky. My experience is that it's better to favour complete knowledge of concrete types than to minimize knowledge of concrete types and leave them open to extension. That is, pattern matching is generally preferred to polymorphism and it's better to get a compilation error when you add a new subtype than it is to try and always squish your new subtype into a polymorphic interface straitjacket to use virtual dispatch instead. There are other problems with object orientation, particularly the way it produces very pointerful code and isn't friendly to - doesn't take advantage of - high latency high bandwidth memory.

danuker 5y ago

> Alan Kay’s 97 OOPSLA keynote Is it this one? https://www.youtube.com/watch?v=oKg1hTOQXoY https://www.youtube.com/watch?v=oKg1hTOQXoY Edit: I suspect it is this one, at 10:33 Alan says "Actually I made up the term <<object-oriented>>, and I can tell you I did not have C++ in mind."

ncmncm 5y ago
Alan Kay has been redefining what he calls OO for decades. He has lost all credibility. He cribbed OO for Smalltalk from Simula, same as Stroustrup did for C++. (Smalltalk-72 was not OO.) "OO" is just a name for something that already existed. Anyway there is nothing very meritorious about OO: it is sometimes the right thing for part of a problem. But organizing a whole language around it is as idiotic as organizing a car design around making left turns.

barrkel 5y ago

Agents with explicit messages are much closer to Smalltalk OO than virtual methods implemented via dispatch tables, with statically typed arguments. OOP has its place. I think it's decent in the small - when you're dealing with data structures which inherently have state and need to maintain invariants - and it's decent, in the agent form, in the large, where you have encapsulated state in separate agents which communicate with one another using messages, as long as you have other actor-model things like fault tolerance. It's in the middle, when you're trying to write a big app filled with communicating mutable objects with lots of mutual references, that things can get pretty sticky. My experience is that it's better to favour complete knowledge of concrete types than to minimize knowledge of concrete types and leave them open to extension. That is, pattern matching is generally preferred to polymorphism and it's better to get a compilation error when you add a new subtype than it is to try and always squish your new subtype into a polymorphic interface straitjacket to use virtual dispatch instead. There are other problems with object orientation, particularly the way it produces very pointerful code and isn't friendly to - doesn't take advantage of - high latency high bandwidth memory.