4 ms·

It's a Faustian bargain. It blesses Javascript with a wider audience, less initial balking by new JS programmers, and a few characters for established JS progra

by sago 11y ago

It's a Faustian bargain. It blesses Javascript with a wider audience, less initial balking by new JS programmers, and a few characters for established JS programmers. But it does so by deliberately misleading programmers by naming the syntax to be the same as the thing they think they want, but JS doesn't contain. That seems like a dick move that condemns a whole slew of new developers to permanent misunderstanding of what they're writing, and a fundamental lack of clarity on prototypical inheritance. I will use it. Because syntactic sugar in this case does save some work. But I'm very conscious the code has swapped superficial clarity for deep lies. I suspect Stack Overflow will overflow with even more 'javascript OO is broken' questions and the MDN article won't make more than a dent on clearing up that (deliberate) confusion. I agree with Crockford on this.

frik 11y ago
I agree with Crockford too. It's Microsoft, Eich & co that pushed the class syntax based on ideas that originated in TypeScript. I am very grateful to Crockford for the "Good Parts" book and JS5 - I like that lean approach.
TazeTSchnitzel 11y ago
The flexibility of prototypical inheritance is one of JavaScript's greatest assets. JavaScript: The Good Parts includes several different approaches to OOP which prototypes make possible. `class` just picks one and pretends the rest never existed.
- frik 11y ago
  Exactly! Sadly many misunderstand JavaScript and don't even know or misunderstand prototype-based inheritance: https://en.wikipedia.org/wiki/Prototype-based_programming https://en.wikipedia.org/wiki/Prototype-based_programming Lua is another well know language that has prototype-based inheritance.
- chc 11y ago
  I don't see what's wrong with that. Converging on one way of doing things is part of the purpose of a standard. We still have the option of implementing a different method if we prefer, just as much as we ever did.
  - angersock 11y ago
    If it's truly a standard, there should be no other options. Instead, this sets the stage for lots of OOPish JS which feels very different from a lot of existing code out there, and will result in awkward shims to interface the different paradigms. We already see such ugliness in C++.
    - chc 11y ago
      > If it's truly a standard, there should be no other options. That's a bit strong. Most languages come with a standard set of data structures, but that doesn't mean they make it impossible to implement other data structures if it suits you (e.g. few languages include binary trees as a standard data type, but that doesn't mean you can't use them). C includes standard string algorithms, but that doesn't mean you can't write your own — you can even create your own string type if C strings are problematic for some reason. Many things in many languages are there to offer a reasonable default that is generally useful. This seems along those lines to me.
    - coldtea 11y ago
      >If it's truly a standard, there should be no other options. That has never been the case with most standards. No see why start now. If it's a standard, it should just be present to all engines, and (but not necessarily) the most popular option. Nothing about it being a standard necessitates it should be "the only option". >Instead, this sets the stage for lots of OOPish JS which feels very different from a lot of existing code out there Quite the opposite. This sets the stage for finally having code that looks THE FUCKING SAME as other code. Instead of 200 ad-hoc implementations of the same exact OOP pattern -- which is what we have now.
spion 11y ago
Seems like people keep saying this again and again, despite the fact that there is no single universal implementation of "classes". Are Python classes broken as well?
gwt 11y ago
I couldn't help but laugh when I read your comment and noticed that the author's last name is Faust.
coldtea 11y ago
There's no reason to confine "class" to just mean C++/Java style inheritance, just because it was used that way first. Besides, most people used prototype based inheritance in this exact manner, so it's good to codify and give a concrete implementation, instead of 200 ad-hoc remakes of the same thing. Third, people still get all the prototypal flexibility anyway if they want it.
- sago 11y ago
  > instead of 200 ad-hoc remakes of the same thing I think that's a good argument for including the syntax, though it raises me from 'anti' to 'ambivalent'. But yeah, figuring out random coder's favourite OOP implementation style is an annoyance. Here Crockford seems to be a bit part of the problem: he seems to recommend a whole new approach every couple of years. His recommendations to never use 'new' (and now, don't use 'this') make it a pain to use other people's objects. I wonder if a better consensus might be the best of all worlds.
  - abecedarius 11y ago
    Well, I was using thisless style all along, and it's nice to get company. I'm a little saddened 'class' will probably win out.
  - wnevets 11y ago
    > he seems to recommend a whole new approach every couple of years you make that sound like a negative. If you find a 'better' way, why not use it?
    - sago 11y ago
      Indeed, the problem is on code bases or teams with multiple ways of doing the same thing. I define new objects with. var foo = Object.create(bar); You do var foo = new Bar(); Amy does var foo = Bar(); and Ellen does var foo = Bar.create(); For many values of 'better', the advantage is much smaller than the additional burden. Thus I have no problem with him finding better ways, but his influence and his way of presenting things as the one best solution causes issues, in my experience.
chimeracoder 11y ago
> That seems like a dick move that condemns a whole slew of new developers to permanent misunderstanding of what they're writing, and a fundamental lack of clarity on prototypical inheritance. Do you feel the same way about Python's use of the word 'class'? Because Python also uses prototypical inheritance under-the-hood. The abstraction is clean enough that most people don't know the difference, but it still really is "just" prototypes down there if you peel back the layers.
- sago 11y ago
  Python didn't used to have such flexible classes. It has migrated that way over time. So 'dick move' doesn't seem to be a valid criticism, to me. That said, Python is a hybrid under the hood. It has become more prototypal over time, but still enforces the distinctions between classes and instances. I personally think that the opportunity to fundamentally open Python to a better object model was missed when Metaclasses were added. I like Metaclasses in Python, I think they need to be there, and help all kinds of tasks. But it might have been better still to support full prototypal inheritance at that point. The complaint I'm making is definitely true of Python though, because it dresses its objects in the outfit of classes and instances, few programmers end up understanding the underlying model and how it can be used to improve their code. And, because of that, it is unwise to use those techniques in code that will be written and maintained by a team. I tend to get nervous of code that uses custom Metaclasses, for example, because of the burden of education is imposes on a project. I'd prefer a situation where Prototypal inheritance was actually taught as the Javascript approach. But perhaps that is utopian and naive.

by sago 11y ago

frik 11y ago

I agree with Crockford too. It's Microsoft, Eich & co that pushed the class syntax based on ideas that originated in TypeScript. I am very grateful to Crockford for the "Good Parts" book and JS5 - I like that lean approach.

TazeTSchnitzel 11y ago

The flexibility of prototypical inheritance is one of JavaScript's greatest assets. JavaScript: The Good Parts includes several different approaches to OOP which prototypes make possible. `class` just picks one and pretends the rest never existed.

frik 11y ago
Exactly! Sadly many misunderstand JavaScript and don't even know or misunderstand prototype-based inheritance: https://en.wikipedia.org/wiki/Prototype-based_programming https://en.wikipedia.org/wiki/Prototype-based_programming Lua is another well know language that has prototype-based inheritance.
chc 11y ago
I don't see what's wrong with that. Converging on one way of doing things is part of the purpose of a standard. We still have the option of implementing a different method if we prefer, just as much as we ever did.
- angersock 11y ago
  If it's truly a standard, there should be no other options. Instead, this sets the stage for lots of OOPish JS which feels very different from a lot of existing code out there, and will result in awkward shims to interface the different paradigms. We already see such ugliness in C++.
  - chc 11y ago
    > If it's truly a standard, there should be no other options. That's a bit strong. Most languages come with a standard set of data structures, but that doesn't mean they make it impossible to implement other data structures if it suits you (e.g. few languages include binary trees as a standard data type, but that doesn't mean you can't use them). C includes standard string algorithms, but that doesn't mean you can't write your own — you can even create your own string type if C strings are problematic for some reason. Many things in many languages are there to offer a reasonable default that is generally useful. This seems along those lines to me.
  - coldtea 11y ago
    >If it's truly a standard, there should be no other options. That has never been the case with most standards. No see why start now. If it's a standard, it should just be present to all engines, and (but not necessarily) the most popular option. Nothing about it being a standard necessitates it should be "the only option". >Instead, this sets the stage for lots of OOPish JS which feels very different from a lot of existing code out there Quite the opposite. This sets the stage for finally having code that looks THE FUCKING SAME as other code. Instead of 200 ad-hoc implementations of the same exact OOP pattern -- which is what we have now.

spion 11y ago

Seems like people keep saying this again and again, despite the fact that there is no single universal implementation of "classes". Are Python classes broken as well?

gwt 11y ago

I couldn't help but laugh when I read your comment and noticed that the author's last name is Faust.

coldtea 11y ago

There's no reason to confine "class" to just mean C++/Java style inheritance, just because it was used that way first. Besides, most people used prototype based inheritance in this exact manner, so it's good to codify and give a concrete implementation, instead of 200 ad-hoc remakes of the same thing. Third, people still get all the prototypal flexibility anyway if they want it.

sago 11y ago
> instead of 200 ad-hoc remakes of the same thing I think that's a good argument for including the syntax, though it raises me from 'anti' to 'ambivalent'. But yeah, figuring out random coder's favourite OOP implementation style is an annoyance. Here Crockford seems to be a bit part of the problem: he seems to recommend a whole new approach every couple of years. His recommendations to never use 'new' (and now, don't use 'this') make it a pain to use other people's objects. I wonder if a better consensus might be the best of all worlds.
- abecedarius 11y ago
  Well, I was using thisless style all along, and it's nice to get company. I'm a little saddened 'class' will probably win out.
- wnevets 11y ago
  > he seems to recommend a whole new approach every couple of years you make that sound like a negative. If you find a 'better' way, why not use it?
  - sago 11y ago
    Indeed, the problem is on code bases or teams with multiple ways of doing the same thing. I define new objects with. var foo = Object.create(bar); You do var foo = new Bar(); Amy does var foo = Bar(); and Ellen does var foo = Bar.create(); For many values of 'better', the advantage is much smaller than the additional burden. Thus I have no problem with him finding better ways, but his influence and his way of presenting things as the one best solution causes issues, in my experience.

chimeracoder 11y ago

> That seems like a dick move that condemns a whole slew of new developers to permanent misunderstanding of what they're writing, and a fundamental lack of clarity on prototypical inheritance. Do you feel the same way about Python's use of the word 'class'? Because Python also uses prototypical inheritance under-the-hood. The abstraction is clean enough that most people don't know the difference, but it still really is "just" prototypes down there if you peel back the layers.

sago 11y ago
Python didn't used to have such flexible classes. It has migrated that way over time. So 'dick move' doesn't seem to be a valid criticism, to me. That said, Python is a hybrid under the hood. It has become more prototypal over time, but still enforces the distinctions between classes and instances. I personally think that the opportunity to fundamentally open Python to a better object model was missed when Metaclasses were added. I like Metaclasses in Python, I think they need to be there, and help all kinds of tasks. But it might have been better still to support full prototypal inheritance at that point. The complaint I'm making is definitely true of Python though, because it dresses its objects in the outfit of classes and instances, few programmers end up understanding the underlying model and how it can be used to improve their code. And, because of that, it is unwise to use those techniques in code that will be written and maintained by a team. I tend to get nervous of code that uses custom Metaclasses, for example, because of the burden of education is imposes on a project. I'd prefer a situation where Prototypal inheritance was actually taught as the Javascript approach. But perhaps that is utopian and naive.