[colllectorof]

Alan Kay spent the last 40 years educating people on OOP and system design. His talks and research papers are now widely available on the internet. There are free, modern and easy-to-use versions of Smalltalk. Anyone who still remains ignorant about fundamental ideas behind classic OOP and the paradigm's history is willfully ignorant.

[throwaway894345]

Lots of OOP proponents disagree strongly with Kay’s definition of OOP, and his definition certainly doesn’t reflect the way the most popular self-described OOP languages are written today. Notably, Smalltalk has a negligible share of the market, so why should anyone waste time debating Kay/Smalltalk’s notions of OOP when they are at best niche?

Further, and more relevant to the thread at hand: it’s not clear to me that Kay’s notion of OOP considered inheritance to be a critical feature. To quote him:

> I felt somewhat the same way about inheritance as I did about types, in that both needed to be a lot better than they were in order to pay for the overheads and pitfalls of using them.

[AdieuToLogic]

> Notably, Smalltalk has a negligible share of the market, so why should anyone waste time debating Kay/Smalltalk’s notions of OOP when they are at best niche?

Objective-C[0] is C with Smalltalk's "notions of OOP." Objective-C has been the dominant programming language for making macOS and iOS programs since OS-X was first released. Swift[1] is taking over the role Objective-C once held alone, but Swift's roots in Smalltalk's "notions of OOP" are easily discerned.

0 - https://en.wikipedia.org/wiki/Objective-C 1 - https://en.wikipedia.org/wiki/Swift_(programming_language)

[Zababa]

I think one problem here is that you can't really compare Objective-C to let's say Java as they are used for different purpose. Swift and Objective-C have negligable market share outisde of the Apple ecosystem, and Java or C# have a negligable market share inside. So it's not a Alan Kay OOP/not Alan Kay OOP split, but a rest of the world/Apple split.

[rytor718]

I think I agree with you. However to the parents point: i think the implication is we might be enlightened about why Alan defines OOP the way he does when we contextualize it with Smalltalk, the language in which he used it. That's a fair point.

But again, you're right: most of us aren't familiar with Smalltalk and so find the very idea of reading such papers daunting at best. I think I'll finally try it though ...it can't be that hard of a language to grasp and it may well lead to some insights about why OOP, as defined by Mr. Kay, is defined as such.

[throwaway894345]

> I think I agree with you. However to the parents point: i think the implication is we might be enlightened about why Alan defines OOP the way he does when we contextualize it with Smalltalk, the language in which he used it. That's a fair point.

I absolutely agree that understanding Kay and Smalltalk can help one become a better programmer and give context into the history of OOP. But it can't be interpreted as anything other than a semantic deflection in the context of a response to substantial criticism.

[karmakaze]

I've never heard this brought up before. What's the distinctions? The thing I've noticed and found lacking in modern OOP is that it tends to be class-based without metaclasses or metaprogramming. Is there something else? Static typing is also something that not in Smalltalk, but that shouldn't change the network shape of objects.

[throwaway894345]

Here are some of the definitions I've heard:

* OOP is about message passing (where message passing is NOT method invocations)

* OOP is about message passing (where message passing can be method invocations)

* OOP is about encapsulation (never mind that most/all paradigms make extensive, idiomatic use of encapsulation--some OOP proponents suggest encapsulation implies constructors that do lots of work, take ver few arguments, and make the class virtually untestable, others argue that this is an "abuse" of OOP or "bad programming")

* OOP is about inheritance

* OOP is a Kingdom-of-nouns programming style (effectively Joe Armstrong's "You wanted a banana but what you got was a gorilla holding the banana and the entire jungle" observation)

For all of these definitions, I've heard many OOP proponents argue that these things are not true OOP (typically without rebuke from other OOP proponents in the forum, bizarrely).

In my opinion, OOP must be defined by the things that distinguish it from other paradigms. Considering encapsulation and method calls are both fundamental to other paradigms, these cannot be defining characteristics of OOP. Additionally, any defining characteristic of OOP must be shared by languages that are virtually universally recognized as OOP, which means that message passing in a non-method-call sense must be excluded. That generally leaves inheritance, "extreme encapsulation" (untestable constructors), and kingdom-of-nouns programming styles.

I don't think the "class-based" thing is meaningful because apart from inheritance there's not much to distinguish a "class" from a struct in Go or Rust (in both cases you can associate methods to the struct for interface polymorphism) which are generally not considered to be "OOP languages" (and Go certainly doesn't have metaclasses or metaprogramming).

> Static typing is also something that not in Smalltalk, but that shouldn't change the network shape of objects.

I agree that static typing is not a defining characteristic of OOP, and I've never heard anyone argue that it is.

[karmakaze]

A thing common to OOP that's missing from this list is localizing data and behaviour together, and the tell-dont-ask way of getting things done in OOP.

I meant that the newer less-pure-OOP languages tend to be statically typed vs Smalltalk etc where objects have behaviours but not compile-time shapes.

[pulse7]

* message passing in Smalltalk is implemented as method invocation (the same is in Java, C#, C++, ...) * encapsulation in Smalltalk: all fields are private/hidden (but: all methods are public)

[karmakaze]

This only seems true for the case of simply defined methods. Differences arising from being able to do late binding is better described on Dynamic Dispatch wiki page[0].

[0] https://en.wikipedia.org/wiki/Dynamic_dispatch#Dynamic_dispa...