[ahartmetz]

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.

[shevy-java]

> 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.

[Blikkentrekker]

> 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.

[jqpabc123]

private data, convenience

Which can be easily achieved without OOP.

[Blikkentrekker]

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.

[pjmlp]

In fact, to a certain point of view, OOP is a way to have modules bind to variables, and being extensible.

[jqpabc123]

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".

[pjmlp]

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.

[pitched]

That upfront convenience here leads to a long tail of job security when it inevitably goes spaghetti. Win-win!

[gf000]

Spaghetti ~ complexity ~ entropy.

That's the natural order of things that many people work in, I doubt any "general loosely defined paradigm" can be absent from the inevitable.

[mpweiher]

> Alan Kay's distaste for (static) types

Citation needed.

TFA quotes him saying almost the opposite:

> (I'm not against types, but I don't know of any type systems that aren't a complete pain, so I still like dynamic typing.)