5 ms·

I think that's the argument -- naming is hard. Most JS libraries want to expose a class-based model -- call it class(es) -- and often to appeal to the non-proto

I think that's the argument -- naming is hard. Most JS libraries want to expose a class-based model -- call it class(es) -- and often to appeal to the non-prototypical crowd. Tutorials and documentation are rife with Java'esque examples. Instead, said JS libraries should possibly be exposing said `new Class()` as `new Delegate()`.

protomyth 14y ago
"often to appeal to the non-prototypical crowd" Isn't that the sad part? Its like Java / C++ is it for a lot of people and every other language has to fit that pattern.
- coldtea 14y ago
  Or it might be that the prototype thing never really caught on and people want something more class like. Why assume prototypes are better or that people should adapt to whatever (potentially BS) way a language offers for organizing code, instead of the other way around (languages should adapt to the way people want to use them).
  - protomyth 14y ago
    I don't think it was given a chance, and the language is prototype-based. It's like programming Smalltalk like it FORTRAN.
    - PommeDeTerre 14y ago
      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
      >I don't think it was given a chance Well, it will be given one. With ES6 and it's class sugar. And people complain about it. >It's like programming Smalltalk like it FORTRAN. If that's what you want to do (and it works), then why not? Especially if that's what almost everybody using Javascript seems to want to do, and each utility library invents its own non compatible way of doing it. Now, you picked a more flexible language first in your example, but how about "programming Java like it was Clojure" or "programming BASIC like it was Python"? Doesn't sound so negative anymore, does it? Plus, isn't that "programming X like it was Y" what tons of people do in Javascript, when they use Clojurescript (like Clojure), Coffeescript (like Ruby), Amber.js (like Smalltalk) etc etc? The semantics of the language remain JS underneath (prototypes, floats, etc -- it's not "true" Ruby, Smalltalk, Clojure), but you get a different facade on top. I don't see many complaining for that.
      - protomyth 14y ago
        "Now, you picked a more flexible language first in your example, but how about "programming Java like it was Clojure" or "programming BASIC like it was Python"? Doesn't sound so negative anymore, does it?" Yep, sounds just as bad. You are programming for something other than the language's strengths. You are also doing something that makes your code different from its conventions. Plus, you aren't learning a new way of expressing the code or why the language designer did what they did, so you won't see the solutions a new language affords. Cross compilers generated code is not meant to interop with hand written code. That is a different game.
    - tracker1 14y ago
      Having seen and worked on enough VB apps in the late 90's that looked like COBOL/FORTRAN, I can't agree more... I hate abstraction for the sake of.. and really, a lot of JS "Class" libraries are mostly that.

protomyth 14y ago

"often to appeal to the non-prototypical crowd" Isn't that the sad part? Its like Java / C++ is it for a lot of people and every other language has to fit that pattern.

coldtea 14y ago
Or it might be that the prototype thing never really caught on and people want something more class like. Why assume prototypes are better or that people should adapt to whatever (potentially BS) way a language offers for organizing code, instead of the other way around (languages should adapt to the way people want to use them).
- protomyth 14y ago
  I don't think it was given a chance, and the language is prototype-based. It's like programming Smalltalk like it FORTRAN.
  - PommeDeTerre 14y ago
    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
    >I don't think it was given a chance Well, it will be given one. With ES6 and it's class sugar. And people complain about it. >It's like programming Smalltalk like it FORTRAN. If that's what you want to do (and it works), then why not? Especially if that's what almost everybody using Javascript seems to want to do, and each utility library invents its own non compatible way of doing it. Now, you picked a more flexible language first in your example, but how about "programming Java like it was Clojure" or "programming BASIC like it was Python"? Doesn't sound so negative anymore, does it? Plus, isn't that "programming X like it was Y" what tons of people do in Javascript, when they use Clojurescript (like Clojure), Coffeescript (like Ruby), Amber.js (like Smalltalk) etc etc? The semantics of the language remain JS underneath (prototypes, floats, etc -- it's not "true" Ruby, Smalltalk, Clojure), but you get a different facade on top. I don't see many complaining for that.
    - protomyth 14y ago
      "Now, you picked a more flexible language first in your example, but how about "programming Java like it was Clojure" or "programming BASIC like it was Python"? Doesn't sound so negative anymore, does it?" Yep, sounds just as bad. You are programming for something other than the language's strengths. You are also doing something that makes your code different from its conventions. Plus, you aren't learning a new way of expressing the code or why the language designer did what they did, so you won't see the solutions a new language affords. Cross compilers generated code is not meant to interop with hand written code. That is a different game.
  - tracker1 14y ago
    Having seen and worked on enough VB apps in the late 90's that looked like COBOL/FORTRAN, I can't agree more... I hate abstraction for the sake of.. and really, a lot of JS "Class" libraries are mostly that.