Having spent a long time with Java I believe I understand the limits of this style of coding; in my considered opinion, composition is almost always better than inheritance. This is true regardless of the type of inheritance, be it prototypal or class-based (in appearance or reality). Therefore, adding features to JS to make class-like inheritance slightly better is not a trade-off I would make, favoring a simpler language over a feature who's use shouldn't be encouraged.
OOP doesn't necessarily imply inheritance, I use composition quite a lot in JS because it tends to make code much more readable for others. Complex object hierarchies in prototype-based languages can become very confusing very quickly.
I disagree; there's nothing pure about Java as an OOP language. In an OOP language, as defined by Alan Kay - who coined the term and popularized the concept - the key characteristics are that everything is an object and objects send messages to each other, while hiding their own state. Classes are not fundamental, but if they exist, they must be objects themselves.
As for JavaScript, the fact that people tend to use sealed closures is not a defining characteristic, anymore than having final classes. JavaScript has Prototypes, and they can be extended just fine.
"[java]’s a pop culture. A commercial hit record for teenagers doesn’t have to have any particular musical merits."
Yeah, either way it is objects. Traits feel so much more flexible though; and more natural a layer over JS object-orientedness. It also makes it a pain that there are some important semantics missing while using classes in JS. Someitmes Java feels much better.
Important note: the writer says they started on Java and had trouble grasping OOP concepts. No wonder, because Java is not an object-oriented language—it is a class-oriented language. This is especially apparent from the inheritance mechanisms.
JavaScript, on the other hand, is an object-oriented language down to its prototypal inheritance. There are no classes, only objects and primitives (which can get transparently promoted to objects).
When people talk about something being simple (or complex), they're talking about how many "things" there are in the concept, rather than how easy or intuitive it is to understand (since that's subjective, as pointed out).
Prototypal inheritence is seen as simpler because conceptually it involves less "things". Both JS and Java have runtimes with values containing basic data (strings, ints, bools etc) as well as objects. Where they differ is that JS has first class functions (meaning functions are also values just like basic data and objects), which is what enables prototypal inheritance. And Java has a compile time where it generates static objects (classes) that aren't values and can't be changed, that's what enables classical inheritance.
It's generally considered that conceptually the functional approach is simpler, because in those languages functions adhere to the same rules as objects and other data, you can add new ones, remove them, move them around, copy them into a different variable etc. So all the "things" that apply to working with functions are just the same "things" that work on everything else, there's nothing really extra there, you don't need all these special rules and concepts like "reflection" where you're "reaching into the internals" of the running program or whatever it is in Java, because you don't have any "internals" to reach into. Nothing is happening at some compile time before the code actually runs, and nothing is static or out of bounds.
None of that really has much to do with prototypal inheritance itself. But it's relevant in that you can't just pick which kind of inheritance to use, you need the language constructs that enable them, so they're part of the complexity. The two forms of inheritance are basically the same thing, you just have an object with your functions on it that has a special label saying "if you don't find what you're looking for, look at this object instead". The difference is that in Javascript that label is just a standard property on an object, that can hold another object. Whereas in Java, that label is an "extends" or "inherits" clause on class that's wired up at compile time, and at runtime it's treated as static and outside of the programmer's control.
This seems rather un-self-aware. Yes, "class Food { etc. }" feels more intuitive to you than how it works in JS because you learned on the classical inheritance pattern. But classical inheritance is not fundamentally easier to understand than prototypical inheritance. You've just used it for so long that you don't remember what it was like to see it as a newcomer.
If you want to be fair, this should be called "the problem with OO programming", and the summary of the problem is that it's complicated and requires that you learn a lot of counterintuitive concepts.
Inheritance is no fundamental property of OO systems, and JavaScript has always supported it anyway (it just did not provide syntactic sugar).
JavaScript always has been an object-oriented language - arguably just not a partcularly well-designed one, and not a pure one (as not all computation happens through message passing).
This way I can say that Java supports OO inheritance and can emulate prototypal inheritance (this can be done in C# and I suspect in latest Java). I think the correct statement is that "JavaScript supports a simple OOP model".
but it has prototypal inheritance, which is an equally valid inheritance scheme, which allows any object to act as a class.
It's a pointless argument, but many people like the way javascript inheritance works. Discounting it because it doesn't act how you want is not a fair judgement.
Javascript supports prototypal inheritance natively and it works well. The problem is people trying to fit every java oo concept in js, ending up writing unreadable mess.
>This seems rather un-self-aware. Yes, "class Food { etc. }" feels more intuitive to you than how it works in JS because you learned on the classical inheritance pattern. But classical inheritance is not fundamentally easier to understand than prototypical inheritance.
Classical inheritance IS easier to understand compared to how prototypical inheritance was implemented in Javascript --and it's obvious from the examples he gives, and all the workarounds to use prototypical inheritance correctly in all the major JS frameworks.
The implementation details of prototype inheritance should not leak to the language, but in JS, they do.
To be fair, JavaScript is also an extremely bad OOP language.
And I’m not complaining about its prototypical inheritance either (I actually like it), but the fact that it tries to hide its prototypical nature under a Java like veneer.
I was pretty much turned off by "At the very least it needs a de-facto standard way of doing object-oriented programming, having the choice between classical, prototypal, or, sure, why not lazy inheritance is not doing it for me." Javascript has one way of doing oop. It's prototypal. You can fake classical if you want but that doesn't negate the fact that the language itself is still prototypal.
reply