3 ms·

I will omit language war you both (parent and grandparent) seem to like waging and I'll go straight to the point. Which is that OO based on prototypes is stric

I will omit language war you both (parent and grandparent) seem to like waging and I'll go straight to the point. Which is that OO based on prototypes is strictly more powerful than popular class based ones. Which is proven by the very fact you mention: people are writing class-based OO implementations in JavaScript with easy, one can create such an implementation in under 100 LOC. So if you think that "superiority" is determined by expressive power, then (popular) class based OO sucks balls in this comparison :) I'm including the 'popular' qualification because thinking about class based object orientation in terms of C++ and Java is rather limited. If take a look at Smalltalk you'll see wonders like #become:. Ruby has implemented substantial subset of what Smalltalk provides and Python, although through really ugly hacks, is still able to replicate prototype-ness of JS. This hints us to the real problem I think you missed, I mean age old difference between static and dynamic typing. Things like Google's Closure Compiler seem to suggest that static typing is desirable in the large projects. And while JITing can alleviate most of the performance problems, maintenance still remains to be a pain in the ass. This same thing applies to class and prototype based OO - while more expressive for the most part, prototypes are not as maintenance friendly as classes are. All sorts of tools, when working with classes, can provide you autocompletion, for example - it's much, much harder with prototypes, which can change at any moment. So, to summarize, I think you blame the right thing but for incorrect reason. Prototype based OO is "better" than class based in terms of expressiveness, but "worse" in terms of maintenance (for now at least). As everything, both techniques have a place in programming and it's just stupid to bash one or the other.

PommeDeTerre 14y ago
I don't think the assertion that JavaScript's prototype-based OO is more expressive because it lets you fake partial implementations of class-based OO with relative ease is true. Now, if we could reliably implement class-based OO systems comparable to, or even better than, those found in Java, C#, C++, Python, Ruby, and Smalltalk, for example, then maybe we could say prototype-based OO is more expressive. However, all we end up with are multiple half-assed (for a lack of a better term) approaches, each of them critically incomplete in one way or another, and often incompatible with one another, too. This creates the integration and maintenance headaches that should be more than apparent to anyone who has worked on any sizable JavaScript code base. In fact, I think we see the opposite in reality. It's much more effective to implement prototype-based OO systems using class-based OO languages. We see exactly this with the major JavaScript implementations (i.e., prototype-based OO systems) today being written in C++. So prototype-based OO fails to deliver both in terms of expressiveness and maintainability. It is just a worse technique, when considering the facts. Trying to pretend it's good at things it clearly isn't good at doesn't make much sense to me. And there's no "language war". C and C++ do the vast bulk of real work today. No other languages today can compare to them, and the ones that try still depend very heavily on one or both.
- klibertp 14y ago
  > C and C++ do the vast bulk of real work today. That's true, but I just have to ask: so what? I, for one, don't subscribe to the theory that popularity equals quality. Although both C and C++ are immensely popular in terms of code written in them that doesn't mean they're the last word in language design. > No other languages today can compare to them, and the ones that try still depend very heavily on one or both. I don't understand what you mean by "compare to them". If you mean in terms of features - sure there are languages more advanced. If you mean in terms of popularity then I can only say I find such comparisons meaningless. > Now, if we could reliably implement class-based OO systems comparable to, > or even better than, those found in Java, C#, C++, Python, Ruby, and Smalltalk, > for example, then maybe we could say prototype-based OO is more expressive. We can do this (modulo "reliably", which I don't understand what you mean by) and that's the problem. You yourself explain this: > However, all we end up with are multiple half-assed That's exactly the case. Java, C++, Python and Ruby are extremely incompatible with each other. No wonder that JS implementations of ideas taken from those languages are still incompatible - although less so than originals between themselves. It's also not that strange that they are incomplete - given that everything you'd like to do in class-based system you can do with prototypes there is simply no need for frameworks being complete. Can you post a few examples of what is possible in Java and not possible in JavaScript? Also remember that language designers can alter syntax to better support their systems, so we need to exclude syntax from comparison. > It's much more effective to implement prototype-based OO systems using class-based OO languages. I don't know if it's impossible, but your examples are flawed. Of course you can write any language in any language, like JS VMs are. But that's completely different matter, I was talking about using the language itself in a prototype based manner. I suspect that, due to static and low-level nature of classes in C++ it's completely, utterly impossible to replicate JS object system inside C++. That you can write interpreter that implements this system is obvious and not interesting at all. As a counter example, in Python you could, with careful use of metaclasses and implementation details of classes and objects create objects whose methods lookup order and semantics of would be the same or close to those of prototype based JS - in the language itself. ======= Your arguments fail to prove that prototype based-ness somehow fails. It does not, in itself, fail in any way. As I wrote above, show what can be done with classes (single inheritance model) that cannot be replicated using JS or better IO prototype semantics - that would be convincing. The fact that JavaScript development is a mess - I won't deny it - proves nothing about prototypes and only a bit about JS. By the way, have you tried Haskell, OCaml or F# and Erlang?

PommeDeTerre 14y ago

I don't think the assertion that JavaScript's prototype-based OO is more expressive because it lets you fake partial implementations of class-based OO with relative ease is true. Now, if we could reliably implement class-based OO systems comparable to, or even better than, those found in Java, C#, C++, Python, Ruby, and Smalltalk, for example, then maybe we could say prototype-based OO is more expressive. However, all we end up with are multiple half-assed (for a lack of a better term) approaches, each of them critically incomplete in one way or another, and often incompatible with one another, too. This creates the integration and maintenance headaches that should be more than apparent to anyone who has worked on any sizable JavaScript code base. In fact, I think we see the opposite in reality. It's much more effective to implement prototype-based OO systems using class-based OO languages. We see exactly this with the major JavaScript implementations (i.e., prototype-based OO systems) today being written in C++. So prototype-based OO fails to deliver both in terms of expressiveness and maintainability. It is just a worse technique, when considering the facts. Trying to pretend it's good at things it clearly isn't good at doesn't make much sense to me. And there's no "language war". C and C++ do the vast bulk of real work today. No other languages today can compare to them, and the ones that try still depend very heavily on one or both.

klibertp 14y ago
> C and C++ do the vast bulk of real work today. That's true, but I just have to ask: so what? I, for one, don't subscribe to the theory that popularity equals quality. Although both C and C++ are immensely popular in terms of code written in them that doesn't mean they're the last word in language design. > No other languages today can compare to them, and the ones that try still depend very heavily on one or both. I don't understand what you mean by "compare to them". If you mean in terms of features - sure there are languages more advanced. If you mean in terms of popularity then I can only say I find such comparisons meaningless. > Now, if we could reliably implement class-based OO systems comparable to, > or even better than, those found in Java, C#, C++, Python, Ruby, and Smalltalk, > for example, then maybe we could say prototype-based OO is more expressive. We can do this (modulo "reliably", which I don't understand what you mean by) and that's the problem. You yourself explain this: > However, all we end up with are multiple half-assed That's exactly the case. Java, C++, Python and Ruby are extremely incompatible with each other. No wonder that JS implementations of ideas taken from those languages are still incompatible - although less so than originals between themselves. It's also not that strange that they are incomplete - given that everything you'd like to do in class-based system you can do with prototypes there is simply no need for frameworks being complete. Can you post a few examples of what is possible in Java and not possible in JavaScript? Also remember that language designers can alter syntax to better support their systems, so we need to exclude syntax from comparison. > It's much more effective to implement prototype-based OO systems using class-based OO languages. I don't know if it's impossible, but your examples are flawed. Of course you can write any language in any language, like JS VMs are. But that's completely different matter, I was talking about using the language itself in a prototype based manner. I suspect that, due to static and low-level nature of classes in C++ it's completely, utterly impossible to replicate JS object system inside C++. That you can write interpreter that implements this system is obvious and not interesting at all. As a counter example, in Python you could, with careful use of metaclasses and implementation details of classes and objects create objects whose methods lookup order and semantics of would be the same or close to those of prototype based JS - in the language itself. ======= Your arguments fail to prove that prototype based-ness somehow fails. It does not, in itself, fail in any way. As I wrote above, show what can be done with classes (single inheritance model) that cannot be replicated using JS or better IO prototype semantics - that would be convincing. The fact that JavaScript development is a mess - I won't deny it - proves nothing about prototypes and only a bit about JS. By the way, have you tried Haskell, OCaml or F# and Erlang?