AFAIU, Simula focused more on types and inheritance and less on late-binding, in particular not of "all things".
Alan Kay's distaste for (static) types is just his opinion and an original contribution of IMO rather dubious value.
After the dust has settled, it seems like the most valuable parts of OOP are private data, convenience (no need to repeat the class name in a method call), good fit for some domains, and interfaces.
> Alan Kay's distaste for (static) types is just his opinion and an original contribution of IMO rather dubious value.
Not at all. matz, creator of ruby, also dislikes static types.
You may begin to realise that good designers and good thinkers dislike
something because there are specific trade-offs.
> it seems like the most valuable parts of OOP are private data, convenience (no need to repeat the class name in a method call), good fit for some domains, and interfaces
This refers more to the practicality of an implementation. Ruby was always better implemented than smalltalk, for instance, even though I think most would say that smalltalk is the more "pure" language. Ruby is more practical though, IMO.
I disagree on the "good fit for some domains" by the way. A great programming language is a great fit in any domain. It just also has to designed well, which is hard, and a trade-off.
> After the dust has settled, it seems like the most valuable parts of OOP are private data, convenience (no need to repeat the class name in a method call), good fit for some domains, and interfaces.
Kay also considers CLOS and related things “true OO” and those do repeat class name in method call.
It's really not clear whether Rust does it or not and it just sidesteps the issues by calling them “structs” and “enums” but fields can be private of course.
Scheme Structs are rather interesting, when you define a struct the language by default also exports getter and setter functions with a predictable name though you can override the default name to give them any name, privacy is simply created by choosing to not export these getter and setter functions from the module.
Privacy on the module level rather than on the class level is a far better pattern to be honest. As in other classes defined in the same module can still have access to them.
And the price for this is constrained flexibility and utility.
Data has value and utility on it's own --- as much as if not more than code that manipulates it. It is often not possible to foresee all the ways it can and will need to be used. So why bind anything to it?
Relational databases were invented to provide flexibility with regard to data. OOP tries to encumber it --- often referred to as an "impedance mismatch".
Proper designed modules also don't expose more than the essentially necessary on their public interface.
Failure to understand this is what leads many into microservice hell, as they try to impose a OS process wall as solution to having failed to properly design a modular architecture.
So what could perfectly be a module with direct calls, ends up being a process talking over IPC mechanisms and much higher latency, with the added fun of distributed systems.
Ironically pretty much OOP without any of the language support.
Alan Kay's distaste for (static) types is just his opinion and an original contribution of IMO rather dubious value.
After the dust has settled, it seems like the most valuable parts of OOP are private data, convenience (no need to repeat the class name in a method call), good fit for some domains, and interfaces.