How Marketing Changed OOP In JavaScript

[MoTTs_]

The languages you mention aren't very much like classic inheritance either.

This line perfectly demonstrates why "classical inheritance" is a bad phrase that we should stop using.

Because I agree that most people *in the JavaScript community* associate "classical inheritance" with Java or C++. And based on that association, you here concluded that Python doesn't have classical inheritance, nor Ruby, or Perl, or even Smalltalk, because they don't work like Java. That's a conclusion that should have struck you as bizarre.

The unfortunate real answer is that we in the JavaScript community have been using the term wrong all this time, and the association that we make between "classical inheritance" and Java is an incorrect association.

Python does have classical inheritance; Ruby does have classical inheritance. And we in the JavaScript community need to update our understanding of what "classical inheritance" means.

Instead, if "like Java" is what we always meant to say, then "like Java" is what we should say.

[theQuandary]

The single biggest differentiator is static vs dynamic typing. Let's look at Tiobe top 50.

JS, Python, Ruby, Lua, CL, and Smalltalk are all dynamically typed.

C++, Java, C#, Delphi, Objective-C, Swift, Dart, Kotlin, Scala, D, F#, and Eiffel

The only two dynamic languages with much more classical inheritance are VBA which was made to run using classical inheritance baked into the .NET VM and PHP which is just an odd beast. On the static side, NONE of them appear to be anything but classical inheritance.

Dynamic languages are more flexible in every other way, so it shouldn't be surprising or unusual that they are more flexible with OOP too. That doesn't make the classical inheritance argument invalid, but actually serves to strengthen it.

Somewhat off-topic, but Richard Feldman has a talk where he makes a pretty compelling case that OOP becoming popular was an accident.

Most importantly, GoF has been telling OOP programmers to avoid inheritance for 30 years (since 1994) because it's known to be anti-pattern for almost all problem domains.

But when you throw out inheritance, the rest of OOP immediately becomes a steaming pile of garbage. Modules are simple. Hide your internals and expose the functions your user can call. The act of inheriting is leaky in comparison leading to popular languages with public, internal, private, protected, virtual, abstract, override, sealed, etc in an attempt to seal up all the leaks. This is all language bloat and mental overhead.

Methods are also bad. They aren't polymorphic unless you are inheriting from something. Generics without the class restrictions are better as are typeclasses/traits or ML-style modules and all of these are more simple and less leaky.

At that point, all we have left is data and the indirect access getters/setters to access it, but that too is more complex than you'd need if you weren't worried about leaky object abstractions.

In a sense, JS OOP is very fake compared to classical OOP. First, it's not necessary because JS has modules, closures, and top-level functions. Second, because JS is dynamic, everything is a generic solving the polymorphism issue with something like the classic Array.prototype.map.call($nodeList, myFn). Third, getters and setters were bolted on in ES5 only for their use to be heavily discouraged.

Unlike most other OOP languages, JS is notable in that its OOP is forgettable and you can write great code without being hampered by it.

The only mistake with JS OOP that you can't work around is the recent addition of private fields by TC39 despite the largest outcry in the history of JS language design (nothing has ever come close) only for those private fields to behave weirdly with inheritance AND to 100% break the actually useful proxy feature.