7 ms·

Not all tools are equal, however. The class-based OO approach of C++ has proven to be practical for real-world software development. The same goes for the appr

Not all tools are equal, however. The class-based OO approach of C++ has proven to be practical for real-world software development. The same goes for the approaches taken by Java and C#, for example. While they can be abused, these approaches generally provide a usable balance between conceptual comprehensibility, consistency, modularity, code sharing/reuse, and the ability to model a variety of realistic domains. The same can't be said of JavaScript's prototype-based OO. It's not that people have trouble understanding it; they know it perfectly well. It's just that, when being used to write real-world software, it is nowhere near as convenient and practical as class-based OO. This is largely why we see so much effort go toward faking class-based OO within so many different JavaScript libraries and applications. JavaScript doesn't natively (yet) provide the tooling that developers need (class-based OO), so they're forced to try to implement it themselves using what JavaScript does offer. And the results usually are quite horrid. The fact that Self, Io and other prototype-based languages never really took off is similarly related, I suspect. Choice between different OO models isn't a bad thing. But when it comes to real-world software development, where there are clients, deadlines, and money to be made, developers need tools that work. Class-based OO has proven itself as a useful tool. Prototype-based OO has been more of a hindrance than a benefit, on the other hand.

tambourine_man 13y ago
Real world software, as you say, with money, clients and deadlines, is written in JavaScript all the time. It's not like it is a toy language or academic research project. It's the widest deployed platform in the world.
- PommeDeTerre 13y ago
  I think that you've missed the fact that we're discussing OO techniques and approaches here, rather than the overall usability of JavaScript. The software I mentioned includes JavaScript written in exchange for money, for clients, facing deadlines, in addition to open source JavaScript projects that may not face such constraints. In such code, we often see prototype-based OO not living up to the hype, and not being suitable for real-world work. Due to these failings, we see many, many developers resort to implementing some limited subset or variant of class-based OO using the functionality that JavaScript does offer. The fact that we see this going on time and time again, involving many different developers, all across the world, over the course of many years should tell us something. I think that "something" is that class-based OO is inherently superior to prototype-based OO for the types of problems typically encountered when developing practical software. Besides, C is the widest-deployed platform in the world. Add in C++, and their share of the market is absolutely huge. Basically every JavaScript implementation today is implemented using one or both of them. The major browsers embedding those JavaScript implementations are implemented in one or both. The operating systems the browsers are running on are implemented in one or both. The servers they're accessing are running operating systems, web servers, database servers, programming language implementations and applications written in C and/or C++. All of this is linked together using various networking devices running code written in C or C++. So every single line of JavaScript code that's executed depends on a stunningly huge amount of C and C++ code also being executed.
  - klibertp 13y ago
    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 13y 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.
- munificent 13y ago
  > Real world software, as you say, with money, clients and deadlines, is written in JavaScript all the time. That says a lot about the lack of alternatives for code that must run in a browser and next to nothing about the merits of prototypes. I have the fortune to work with a bunch of people that worked on Self, or worked with people that did. Many of them told me that after all of that experience, the conclusion they came to was that prototypes don't really work well in practice, even when you have multiple parents like Self. (JS lacks that, which makes it even more painfully limited.) Meanwhile, many JS luminaries, people who understand every corner of the language, are working hard to add class syntax to ES6 (, or defining transpilers that support it (Erik Arvidsson with Traceur, Jeremy Ashkenas with CoffeeScript). I find prototypes interesting. I've implemented my own prototype-based language from scratch to understand them better. As soon as I had it working and started writing code in the language, the first thing I found myself wanting was to add classes to it.
  - PommeDeTerre 13y ago
    It's encouraging to see such functionality at least being proposed for JavaScript. While it doesn't do much to fix many of the other inherent problems that the language is riddled with, it does at least show some small degree of sensibility going forward.
- Executor 13y ago
  Javascript is one of (imo) the most horrendous OO language of all time. No static analysis, horrible scoping/syntax, class declaration, and so on.
pcwalton 13y ago
You keep showing up in unrelated threads talking about how JavaScript is terrible, even when it isn't remotely relevant to the topic at hand. Case in point: the models of Rust and Go have nothing to do with prototype-based OO. Typeclasses as Rust uses are in fact about as far as you can get from prototype-based OO: they are less dynamic, not more dynamic. There is no virtual dispatch involved at all. Neither Rust nor Go have any support for prototype-based OO. I understand you dislike JavaScript, but would you please stop derailing comment threads that have nothing to do with it?
- PommeDeTerre 13y ago
  Patrick, please notice that I replied to pjmlp's comment, which specifically mentioned JavaScript and its prototype-based OO. While the article may be about Rust and Go, some of the discussion here may naturally go beyond the article's content.
  - pcwalton 13y ago
    Apologies, I didn't notice that pjmlp posted about JS.
SeanDav 13y ago
You are doing a lot of hand waving, with very little backup. Where are your credible sources that class based OO is so much better than prototype based OO? Personally I find prototype based OO very powerful and easy to use, but you won't catch me saying it is "better" in any way than class based OO. Once again, where is your proof?
- PommeDeTerre 13y ago
  Decades of personal experience dealing with many large-scale, real-world software systems written by many different developers, using many programming languages offering a variety of OO approaches. With such experience comes the realization that there are big differences between the different approaches. Some are seriously inferior to others. Some generally aren't better or worse than others. Some are obviously better in many ways. Have you ever worked on a significantly large JavaScript-based system that has been created by many developers over the course of several years, or even a decade? I find most people that have will know what I'm talking about. Experiencing it for yourself is much better than any academic citation I could give you.
  - evincarofautumn 13y ago
    I have worked with a relatively large JavaScript system (about 20k lines) and found that the vast majority of maintainability problems had to do with dynamic typing and late binding, not prototypal inheritance. This could be a feature of different codebases making different use of the language.
  - SeanDav 13y ago
    Right, so that was your opinion. Nothing wrong with having an opinion but on HN we try to back our opinions with real world data, otherwise it becomes just a case of he-said, she-said. Have you ever considered that the suitability or otherwise of Javascript for huge projects might be attributed to other aspects of the language, rather than prototype based OO?
    - PommeDeTerre 13y ago

tambourine_man 13y ago

Real world software, as you say, with money, clients and deadlines, is written in JavaScript all the time. It's not like it is a toy language or academic research project. It's the widest deployed platform in the world.

PommeDeTerre 13y ago
I think that you've missed the fact that we're discussing OO techniques and approaches here, rather than the overall usability of JavaScript. The software I mentioned includes JavaScript written in exchange for money, for clients, facing deadlines, in addition to open source JavaScript projects that may not face such constraints. In such code, we often see prototype-based OO not living up to the hype, and not being suitable for real-world work. Due to these failings, we see many, many developers resort to implementing some limited subset or variant of class-based OO using the functionality that JavaScript does offer. The fact that we see this going on time and time again, involving many different developers, all across the world, over the course of many years should tell us something. I think that "something" is that class-based OO is inherently superior to prototype-based OO for the types of problems typically encountered when developing practical software. Besides, C is the widest-deployed platform in the world. Add in C++, and their share of the market is absolutely huge. Basically every JavaScript implementation today is implemented using one or both of them. The major browsers embedding those JavaScript implementations are implemented in one or both. The operating systems the browsers are running on are implemented in one or both. The servers they're accessing are running operating systems, web servers, database servers, programming language implementations and applications written in C and/or C++. All of this is linked together using various networking devices running code written in C or C++. So every single line of JavaScript code that's executed depends on a stunningly huge amount of C and C++ code also being executed.
- klibertp 13y ago
  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 13y 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.
munificent 13y ago
> Real world software, as you say, with money, clients and deadlines, is written in JavaScript all the time. That says a lot about the lack of alternatives for code that must run in a browser and next to nothing about the merits of prototypes. I have the fortune to work with a bunch of people that worked on Self, or worked with people that did. Many of them told me that after all of that experience, the conclusion they came to was that prototypes don't really work well in practice, even when you have multiple parents like Self. (JS lacks that, which makes it even more painfully limited.) Meanwhile, many JS luminaries, people who understand every corner of the language, are working hard to add class syntax to ES6 (, or defining transpilers that support it (Erik Arvidsson with Traceur, Jeremy Ashkenas with CoffeeScript). I find prototypes interesting. I've implemented my own prototype-based language from scratch to understand them better. As soon as I had it working and started writing code in the language, the first thing I found myself wanting was to add classes to it.
- PommeDeTerre 13y ago
  It's encouraging to see such functionality at least being proposed for JavaScript. While it doesn't do much to fix many of the other inherent problems that the language is riddled with, it does at least show some small degree of sensibility going forward.
Executor 13y ago
Javascript is one of (imo) the most horrendous OO language of all time. No static analysis, horrible scoping/syntax, class declaration, and so on.

pcwalton 13y ago

You keep showing up in unrelated threads talking about how JavaScript is terrible, even when it isn't remotely relevant to the topic at hand. Case in point: the models of Rust and Go have nothing to do with prototype-based OO. Typeclasses as Rust uses are in fact about as far as you can get from prototype-based OO: they are less dynamic, not more dynamic. There is no virtual dispatch involved at all. Neither Rust nor Go have any support for prototype-based OO. I understand you dislike JavaScript, but would you please stop derailing comment threads that have nothing to do with it?

PommeDeTerre 13y ago
Patrick, please notice that I replied to pjmlp's comment, which specifically mentioned JavaScript and its prototype-based OO. While the article may be about Rust and Go, some of the discussion here may naturally go beyond the article's content.
- pcwalton 13y ago
  Apologies, I didn't notice that pjmlp posted about JS.

SeanDav 13y ago

You are doing a lot of hand waving, with very little backup. Where are your credible sources that class based OO is so much better than prototype based OO? Personally I find prototype based OO very powerful and easy to use, but you won't catch me saying it is "better" in any way than class based OO. Once again, where is your proof?

PommeDeTerre 13y ago
Decades of personal experience dealing with many large-scale, real-world software systems written by many different developers, using many programming languages offering a variety of OO approaches. With such experience comes the realization that there are big differences between the different approaches. Some are seriously inferior to others. Some generally aren't better or worse than others. Some are obviously better in many ways. Have you ever worked on a significantly large JavaScript-based system that has been created by many developers over the course of several years, or even a decade? I find most people that have will know what I'm talking about. Experiencing it for yourself is much better than any academic citation I could give you.
- evincarofautumn 13y ago
  I have worked with a relatively large JavaScript system (about 20k lines) and found that the vast majority of maintainability problems had to do with dynamic typing and late binding, not prototypal inheritance. This could be a feature of different codebases making different use of the language.
- SeanDav 13y ago
  Right, so that was your opinion. Nothing wrong with having an opinion but on HN we try to back our opinions with real world data, otherwise it becomes just a case of he-said, she-said. Have you ever considered that the suitability or otherwise of Javascript for huge projects might be attributed to other aspects of the language, rather than prototype based OO?
  - PommeDeTerre 13y ago