4 ms·

Prototypal inheritance works well, if you understand it. It's only "wrong" if you're of the Java/C++ OOP religion.

by SomeCallMeTim 11y ago

deleted 11y ago
[deleted]
tolmasky 11y ago
> if you understand it Someday we'll figure out that this is the problem with most features.
bwaxxlo 11y ago
I find most people who have gripes with JS prototypes are the ones who are used to classical inheritance. Overall, the more I understand JS, the more I'm convinces most issues raised are personal preferences.
- atinoda-kestrel 11y ago
  > I find most people who have gripes with JS prototypes are the ones who are used to classical inheritance. Counterpoint: Scheme/Lisp/FP fans also don't tend to like it. Myself included.
  - lispm 11y ago
    Not really. The idea of protypical object-systems is for a large part coming out of the Lisp community (and the Smalltalk community) and was used long before Self or Javascript. Check the works of Henry Lieberman. The Self developers got the idea of 'delegation' from him. Object Lisp was a prototype-based object system used in LMI's Lisp Machine OS and in Macintosh Common Lisp (until it was replaced by the then developed standard CLOS). Various Lisp-based systems were developed in the 'knowledge representation' domain, which are supporting 'prototypes'. Apple for example developed a system called Sk8 in Macintosh Common Lisp, which made extensive use of prototypes for multimedia UI tool development. With the advent of CLOS those were not used for typical OO programming in Lisp - not because people don't like it, but because another standard system was provided.
    - atinoda-kestrel 11y ago
      Oh, I think the idea is plenty neat. It's how it's ended up in JS that I'm not a fan of.
wwweston 11y ago
My comment is arguably overelliptical, so I'm going to 'splain: 1) I agree that the author sounds like a lot of developers who have a "What am I going to do without the exact class semantics I'm used to?" moment when they get to JS, and rather than learn to answer that question, they either decide that it's an inherent black mark on the language or go on a long quest trying to get something more like the semantics of another language in JS (often frustrating because it's almost possible). 2) More importantly, though... implementation inheritance itself is something a lot of thoughtful developers look on with a skeptical eye. Hence Gosling's comment about "I'd leave out classes" if he were starting over with Java, or Golang's interfaces. I wouldn't go so far as to call it "pants-on-head stupid" (I'll reserve contempt on that level for JS linters that enforce a no-semicolon policy), because it can be a nice mechanism for re-use, but it has its problems (fragile base class) and really only ever fits ideally to the extent that the portion of your domain you're modeling is actually a class hierarchy.
- SomeCallMeTim 11y ago
  I come from games, which actually map to OO design better than most domains, from what I can tell. And while I was briefly of the OO religion, I've since recovered and appreciate all paradigms for what they can best accomplish. I'm "Post-OO". :) I do still consider implementation inheritance to be useful. But it's certainly used poorly in a lot of circumstances (along with MOST of OO design, including most of Java), and it may encourage bad habits. And I agree that composition is often a better answer. Depends on what you're doing. Aside: Do JS linters actually enforce a no-semicolon policy in real projects?! I started using jshint and jscs recently in part to enforce the use of semicolons (on the advice of "JavaScript: The Good Parts"). I see that jscs has a "disallowSemicolons" rule, but I didn't know stupidity went to such depths as to actually USE that rule...I thought it was there for completeness...
  - insin 11y ago
    > Aside: Do JS linters actually enforce a no-semicolon policy in real projects? Yes, they do. See https://github.com/feross/standard/ https://github.com/feross/standard/ as a preconfigured example. > (on the advice of "JavaScript: The Good Parts") To paraphrase The Dude: yeah, well, you know, that's just, like, Crockford's opinion, man; whether you want to use them or not, there's tooling to support you either way.

Prototypal inheritance works well, if you understand it. It's only "wrong" if you're of the Java/C++ OOP religion.

deleted 11y ago

[deleted]

tolmasky 11y ago

> if you understand it Someday we'll figure out that this is the problem with most features.

bwaxxlo 11y ago

I find most people who have gripes with JS prototypes are the ones who are used to classical inheritance. Overall, the more I understand JS, the more I'm convinces most issues raised are personal preferences.

atinoda-kestrel 11y ago
> I find most people who have gripes with JS prototypes are the ones who are used to classical inheritance. Counterpoint: Scheme/Lisp/FP fans also don't tend to like it. Myself included.
- lispm 11y ago
  Not really. The idea of protypical object-systems is for a large part coming out of the Lisp community (and the Smalltalk community) and was used long before Self or Javascript. Check the works of Henry Lieberman. The Self developers got the idea of 'delegation' from him. Object Lisp was a prototype-based object system used in LMI's Lisp Machine OS and in Macintosh Common Lisp (until it was replaced by the then developed standard CLOS). Various Lisp-based systems were developed in the 'knowledge representation' domain, which are supporting 'prototypes'. Apple for example developed a system called Sk8 in Macintosh Common Lisp, which made extensive use of prototypes for multimedia UI tool development. With the advent of CLOS those were not used for typical OO programming in Lisp - not because people don't like it, but because another standard system was provided.
  - atinoda-kestrel 11y ago
    Oh, I think the idea is plenty neat. It's how it's ended up in JS that I'm not a fan of.

wwweston 11y ago

My comment is arguably overelliptical, so I'm going to 'splain: 1) I agree that the author sounds like a lot of developers who have a "What am I going to do without the exact class semantics I'm used to?" moment when they get to JS, and rather than learn to answer that question, they either decide that it's an inherent black mark on the language or go on a long quest trying to get something more like the semantics of another language in JS (often frustrating because it's almost possible). 2) More importantly, though... implementation inheritance itself is something a lot of thoughtful developers look on with a skeptical eye. Hence Gosling's comment about "I'd leave out classes" if he were starting over with Java, or Golang's interfaces. I wouldn't go so far as to call it "pants-on-head stupid" (I'll reserve contempt on that level for JS linters that enforce a no-semicolon policy), because it can be a nice mechanism for re-use, but it has its problems (fragile base class) and really only ever fits ideally to the extent that the portion of your domain you're modeling is actually a class hierarchy.

SomeCallMeTim 11y ago
I come from games, which actually map to OO design better than most domains, from what I can tell. And while I was briefly of the OO religion, I've since recovered and appreciate all paradigms for what they can best accomplish. I'm "Post-OO". :) I do still consider implementation inheritance to be useful. But it's certainly used poorly in a lot of circumstances (along with MOST of OO design, including most of Java), and it may encourage bad habits. And I agree that composition is often a better answer. Depends on what you're doing. Aside: Do JS linters actually enforce a no-semicolon policy in real projects?! I started using jshint and jscs recently in part to enforce the use of semicolons (on the advice of "JavaScript: The Good Parts"). I see that jscs has a "disallowSemicolons" rule, but I didn't know stupidity went to such depths as to actually USE that rule...I thought it was there for completeness...
- insin 11y ago
  > Aside: Do JS linters actually enforce a no-semicolon policy in real projects? Yes, they do. See https://github.com/feross/standard/ https://github.com/feross/standard/ as a preconfigured example. > (on the advice of "JavaScript: The Good Parts") To paraphrase The Dude: yeah, well, you know, that's just, like, Crockford's opinion, man; whether you want to use them or not, there's tooling to support you either way.