3 ms·

In what way wasn't it given a chance? The JavaScript community has had well over 15 years to show that prototype-based OO is feasible. Yet we've seen nothing co

In what way wasn't it given a chance? The JavaScript community has had well over 15 years to show that prototype-based OO is feasible. Yet we've seen nothing compelling produced in that time. Whenever it comes to getting real work done, we see JavaScript developers resorting to some imitation of the proper class-based OO functionality made available by so many other languages. At what point will people admit that JavaScript's attempt at prototype-based OO is a miserable failure? At least we're seeing some indication of this finally happening with the latest standardization efforts. It's unfortunate that this is coming so late, however, after so much JavaScript-based software has been written using a hodge-podge of the different ways to fake class-based OO.

protomyth 14y ago
I think we've seen 15 years of people trying to program Javascript like Java. I think we see the same programmers who bitch and moan every time we have a concatenative, Smalltalk(1), or DSL thread about how it is too different. I think we have seen that if it looks like C++ or Java, it needs to act the same way. I guess the old rule about FORTRAN is now true of Java. 1) to quote "how will I ever use and image-based language with source code control?"
wwweston 14y ago
Wow. Axe grind much? > The JavaScript community has had well over 15 years to show that prototype-based OO is feasible. Yet we've seen nothing compelling produced in that time. Nothing compelling produced in JavaScript? A reader could be forgiven at this point for thinking that you're not only unfamiliar with the language, but also largely unfamiliar with what people have done on the web in JS. > Whenever it comes to getting real work done, we see JavaScript developers resorting to some imitation of the proper class-based OO functionality made available by so many other languages. Who's "we"? Look, I don't know what your real criticisms of JavaScript's approach are, since you've chosen to spend your writing energy on making a few comments filled with vague pejoratives rather than any specifics. So I'm going to go on a guess: from your perspective, "proper" OO programming is modeling out the problem domain of the program in a class/type hierarchy, with inheritance relationships as the primary mechanism for code reuse. That can be a helpful way of organizing a program. It works well enough for some problem domains where you've got a lot of related objects that are mostly like some other object, and where the relationships between them are pretty clear. It works particularly well where there's a set of well-established conventions ("patterns") for definitions... or where you're actually writing software where someone's already formally modeled a problem domain in exactly this manner (though not all formally modeled domains are easily amenable to this approach, as anyone who's ever tried to write or use an ORM for non-trivial domain can tell you). But it's not the only way to write software. Heck, it's not the only way to write object oriented software. And a class hierarchy is sometimes not the simplest or the most robust way of approaching a program. The JS devs I know who are best at getting "real work" done recognize this. And they don't spend a lot of time stressing over modeling their programs as a class hierarchy. In some cases where that turns out to be the best model for a problem, it turns out JavaScript will support it (you used words like "imitate" and "fake" but the word "implement" would probably do just as well for a non-polemicist). But much of the time, composition and a bit of shallow prototype delegation or method grafting will do. And that's for the space where objects are helpful... that's to say nothing of the domain where sometimes, functions and a spot of imperative code alone will do the job.
- coldtea 14y ago
  >>The JavaScript community has had well over 15 years to show that prototype-based OO is feasible. Yet we've seen nothing compelling produced in that time. > Nothing compelling produced in JavaScript? No, he means nothing compelling produced with prototypes, without resorting to some tricks to make it class-like. (Did you even notice the context he replied to?) Now, here and there you'll find some prototype usage for what it is. But the overwhelming majority of frameworks, developers, and projects uses a class-like approach.
  - tracker1 14y ago
    And that has led us where. Class-based OO approaches became popular in the mid-90's as a panacea of maintainability and code reuse... This has taken us to "enterprise" frameworks and layers of abstraction that offer very little actual value, and huge amounts of maintenance overhead. In VS/Eclipse, I can't tell you how many times I go through the inheritance chain only to be brick walled into an Interface, and then have to look for the specific/abstracted implementation of said interface. 99/100 times there is only one implementation, and no test coverage to justify said abstraction. So, why do it at all? Because of how strict and constrained said programming environment is. JS doesn't have those levels of restriction, and doesn't need those levels of abstraction and inheritance. You can utilize other patterns and practices... there's more out there than Class based approaches. For example MVC is really seamless in JS... you can have models that are dumb JS objects (they don't need to be inherited from, or to).. and modules that manipulate/use/store said objects. It doesn't need to be so complicated. It isn't that some problems aren't complicated, and don't need some serious use of patterns/factories/IoC... It's simply that in many cases they are done because they "can be" or some overzealous architect thinks they "should" be. I've only ever seen a couple instances where most of these abstraction patterns actually make sense.. and I've been writing software for close to two decades now. As for "but the overwhelming majority of frameworks... use class-like approach" .. arguably the single most used framework/library in use today is jQuery.. and that definitely does NOT use a class-like approach.
    - coldtea 14y ago

protomyth 14y ago

I think we've seen 15 years of people trying to program Javascript like Java. I think we see the same programmers who bitch and moan every time we have a concatenative, Smalltalk(1), or DSL thread about how it is too different. I think we have seen that if it looks like C++ or Java, it needs to act the same way. I guess the old rule about FORTRAN is now true of Java. 1) to quote "how will I ever use and image-based language with source code control?"

wwweston 14y ago

Wow. Axe grind much? > The JavaScript community has had well over 15 years to show that prototype-based OO is feasible. Yet we've seen nothing compelling produced in that time. Nothing compelling produced in JavaScript? A reader could be forgiven at this point for thinking that you're not only unfamiliar with the language, but also largely unfamiliar with what people have done on the web in JS. > Whenever it comes to getting real work done, we see JavaScript developers resorting to some imitation of the proper class-based OO functionality made available by so many other languages. Who's "we"? Look, I don't know what your real criticisms of JavaScript's approach are, since you've chosen to spend your writing energy on making a few comments filled with vague pejoratives rather than any specifics. So I'm going to go on a guess: from your perspective, "proper" OO programming is modeling out the problem domain of the program in a class/type hierarchy, with inheritance relationships as the primary mechanism for code reuse. That can be a helpful way of organizing a program. It works well enough for some problem domains where you've got a lot of related objects that are mostly like some other object, and where the relationships between them are pretty clear. It works particularly well where there's a set of well-established conventions ("patterns") for definitions... or where you're actually writing software where someone's already formally modeled a problem domain in exactly this manner (though not all formally modeled domains are easily amenable to this approach, as anyone who's ever tried to write or use an ORM for non-trivial domain can tell you). But it's not the only way to write software. Heck, it's not the only way to write object oriented software. And a class hierarchy is sometimes not the simplest or the most robust way of approaching a program. The JS devs I know who are best at getting "real work" done recognize this. And they don't spend a lot of time stressing over modeling their programs as a class hierarchy. In some cases where that turns out to be the best model for a problem, it turns out JavaScript will support it (you used words like "imitate" and "fake" but the word "implement" would probably do just as well for a non-polemicist). But much of the time, composition and a bit of shallow prototype delegation or method grafting will do. And that's for the space where objects are helpful... that's to say nothing of the domain where sometimes, functions and a spot of imperative code alone will do the job.

coldtea 14y ago
>>The JavaScript community has had well over 15 years to show that prototype-based OO is feasible. Yet we've seen nothing compelling produced in that time. > Nothing compelling produced in JavaScript? No, he means nothing compelling produced with prototypes, without resorting to some tricks to make it class-like. (Did you even notice the context he replied to?) Now, here and there you'll find some prototype usage for what it is. But the overwhelming majority of frameworks, developers, and projects uses a class-like approach.
- tracker1 14y ago
  And that has led us where. Class-based OO approaches became popular in the mid-90's as a panacea of maintainability and code reuse... This has taken us to "enterprise" frameworks and layers of abstraction that offer very little actual value, and huge amounts of maintenance overhead. In VS/Eclipse, I can't tell you how many times I go through the inheritance chain only to be brick walled into an Interface, and then have to look for the specific/abstracted implementation of said interface. 99/100 times there is only one implementation, and no test coverage to justify said abstraction. So, why do it at all? Because of how strict and constrained said programming environment is. JS doesn't have those levels of restriction, and doesn't need those levels of abstraction and inheritance. You can utilize other patterns and practices... there's more out there than Class based approaches. For example MVC is really seamless in JS... you can have models that are dumb JS objects (they don't need to be inherited from, or to).. and modules that manipulate/use/store said objects. It doesn't need to be so complicated. It isn't that some problems aren't complicated, and don't need some serious use of patterns/factories/IoC... It's simply that in many cases they are done because they "can be" or some overzealous architect thinks they "should" be. I've only ever seen a couple instances where most of these abstraction patterns actually make sense.. and I've been writing software for close to two decades now. As for "but the overwhelming majority of frameworks... use class-like approach" .. arguably the single most used framework/library in use today is jQuery.. and that definitely does NOT use a class-like approach.
  - coldtea 14y ago