3 ms·

The real mess is how in ES6 they (the ES6 WG I mean) are furthering the illusion that JS supports classical OO, which is completely crazy. They should be going

by mcmire 13y ago

The real mess is how in ES6 they (the ES6 WG I mean) are furthering the illusion that JS supports classical OO, which is completely crazy. They should be going the other direction (and I think /be wanted to) but they steered away from that and seem to think that mixing syntaxes and thus concepts is the right move. I would imagine this article series will talk that eventually, though, kind of hard not to.

deleted 13y ago
[deleted]
ax 13y ago
I think BE is a fan of the max-min class proposal... At any rate, naming aside, ES6 classes are simple syntactic sugar for a very common pattern in JS development today. It makes sense to provide a syntactic sugar in this case that makes developer intention clear and reduces boilerplate. TypeScript has (I believe) a mostly compatible implementation of these classes if you want to try them out in today's runtimes.
coldtea 13y ago
>They should be going the other direction Why? If the people want a language changed, most abuse the current prototype system to be more classic class like (including top notch programmers), and there is a demand for it, why not add a proper class syntax, even as a sugar for the common workaround? It's like saying people must adapt to the idiomatic ways of a language without offering any proof that those are better (and no, random qualities like "more flexible" is not necessarily better in actual use). I don't think we should worship "idiomatic" ways of each language. For example, tons of Beans, XML, and boilerplate was the idiomatic Java way, but then projects came along and showed it could be done better (e.g Play). Using every feature under the sun and abusing templates is kind of an idiomatic C++ way, but people are arguing successfully for merely using C++ only as a C with classes and some minimal features.
jarek-foksa 13y ago
JavaScript was a pseudo-classical language from the beginning. JS constructors were and still are the core language feature that clearly tries to mimic classes from Java. I agree that's it's awful, but it can't be depracated or removed from the language because there is so much code relying on it. Evolving JS into language with minimal dynamic classes such as Python or Ruby should be easy as all interfaces are already "classical", you just need to add some syntactic sugar. This approach was already proved to work by CoffeeScript and TypeScript. I can't imagine how JS could be evolved into clean prototypal language such Io without breaking backwards compatibility. There is no hope for JavaScript to become elegant prototypal language because of the design mistakes that were done in the past. All that TC39 / ECMAScript.next committee can do is put even more lipstick on a pig. http://this-plt-life.tumblr.com/post/36425234595/when-somebody-tries-to-explain-javascripts-prototype http://this-plt-life.tumblr.com/post/36425234595/when-somebo... http://this-plt-life.tumblr.com/post/41438931672/when-somebody-says-js-has-a-beautiful-object-model http://this-plt-life.tumblr.com/post/41438931672/when-somebo...
- _getify 13y ago
  Actually, the evolution of the language has been adding "class-like" features over time. It was most definitely not designed originally to mimic classes. That's been the demand of all the classicists coming to the language. There are those of us who wish for the language to not have all those things. In parts 2 and 3, I'll make the case for why I think all those things don't belong in JS and should be removed or avoided.
  - jarek-foksa 13y ago
    There was really little evolution of the language since 1995. It was initially launched as a "perfect complement to Java" [1] and until recently its development was stalled. Constructors and "new" were there from the beginning. Nobody have even noticed the prototypal nature of JS until people like Crockford started evangelising it 10 years later, which in turn resulted in the addition of Object.create() in ES5. [1] http://www2.ldc.lu.se/temadag95/javascript.txt http://www2.ldc.lu.se/temadag95/javascript.txt
    - _getify 13y ago
      I'm not sure the actual history bears out your assertion that 1995 was the fix-point date for all/most of these concepts. AIUI, functions were not originally first-class citizens. My understanding is (and I may very well be incorrect), in these very early days, functions not being objects precluded an awful lot of what we currently "know" to be true about how JS emulates "classes" with function.prototype. I tried to find good citations for this fact, but I'm having trouble finding good "early JavaScript" history. I do know that at least as early as ES1, in mid-1997, we had constructors with prototypes and "new". [1] In any case, besides `Object.create()` which you've noted, here are some other milestones in the evolution of "OO in JS" I could find: `instanceof` was added in JavaScript 1.4 [2], which was sometime after Oct 1998 [3], probably officially in ES3. `Object#isPrototypeOf()` was added in ES3 [4], which was around late 1999. `Object.getPrototypeOf()` was added in ES5 [5], which was around 2009. [1] http://www.ecma-international.org/publications/files/ECMA-ST-ARCH/ECMA-262,%201st%20edition,%20June%201997.pdf http://www.ecma-international.org/publications/files/ECMA-ST... [2] https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Operators/instanceof https://developer.mozilla.org/en-US/docs/JavaScript/Referenc... [3] http://en.wikipedia.org/wiki/Javascript#Version_history http://en.wikipedia.org/wiki/Javascript#Version_history [4] https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Object/isPrototypeOf https://developer.mozilla.org/en-US/docs/JavaScript/Referenc... [5] https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Object/getPrototypeOf https://developer.mozilla.org/en-US/docs/JavaScript/Referenc...
_getify 13y ago
In part 2, which should be published today, I'll be addressing "class { }" and why I think it doesn't belong in JS. I think it's just more "distraction" that moves us away from a better clearer understanding of how [[Prototype]] behavior delegation works.

by mcmire 13y ago

deleted 13y ago

[deleted]

ax 13y ago

I think BE is a fan of the max-min class proposal... At any rate, naming aside, ES6 classes are simple syntactic sugar for a very common pattern in JS development today. It makes sense to provide a syntactic sugar in this case that makes developer intention clear and reduces boilerplate. TypeScript has (I believe) a mostly compatible implementation of these classes if you want to try them out in today's runtimes.

coldtea 13y ago

>They should be going the other direction Why? If the people want a language changed, most abuse the current prototype system to be more classic class like (including top notch programmers), and there is a demand for it, why not add a proper class syntax, even as a sugar for the common workaround? It's like saying people must adapt to the idiomatic ways of a language without offering any proof that those are better (and no, random qualities like "more flexible" is not necessarily better in actual use). I don't think we should worship "idiomatic" ways of each language. For example, tons of Beans, XML, and boilerplate was the idiomatic Java way, but then projects came along and showed it could be done better (e.g Play). Using every feature under the sun and abusing templates is kind of an idiomatic C++ way, but people are arguing successfully for merely using C++ only as a C with classes and some minimal features.

jarek-foksa 13y ago

JavaScript was a pseudo-classical language from the beginning. JS constructors were and still are the core language feature that clearly tries to mimic classes from Java. I agree that's it's awful, but it can't be depracated or removed from the language because there is so much code relying on it. Evolving JS into language with minimal dynamic classes such as Python or Ruby should be easy as all interfaces are already "classical", you just need to add some syntactic sugar. This approach was already proved to work by CoffeeScript and TypeScript. I can't imagine how JS could be evolved into clean prototypal language such Io without breaking backwards compatibility. There is no hope for JavaScript to become elegant prototypal language because of the design mistakes that were done in the past. All that TC39 / ECMAScript.next committee can do is put even more lipstick on a pig. http://this-plt-life.tumblr.com/post/36425234595/when-somebody-tries-to-explain-javascripts-prototype http://this-plt-life.tumblr.com/post/36425234595/when-somebo... http://this-plt-life.tumblr.com/post/41438931672/when-somebody-says-js-has-a-beautiful-object-model http://this-plt-life.tumblr.com/post/41438931672/when-somebo...

_getify 13y ago
Actually, the evolution of the language has been adding "class-like" features over time. It was most definitely not designed originally to mimic classes. That's been the demand of all the classicists coming to the language. There are those of us who wish for the language to not have all those things. In parts 2 and 3, I'll make the case for why I think all those things don't belong in JS and should be removed or avoided.
- jarek-foksa 13y ago
  There was really little evolution of the language since 1995. It was initially launched as a "perfect complement to Java" [1] and until recently its development was stalled. Constructors and "new" were there from the beginning. Nobody have even noticed the prototypal nature of JS until people like Crockford started evangelising it 10 years later, which in turn resulted in the addition of Object.create() in ES5. [1] http://www2.ldc.lu.se/temadag95/javascript.txt http://www2.ldc.lu.se/temadag95/javascript.txt
  - _getify 13y ago
    I'm not sure the actual history bears out your assertion that 1995 was the fix-point date for all/most of these concepts. AIUI, functions were not originally first-class citizens. My understanding is (and I may very well be incorrect), in these very early days, functions not being objects precluded an awful lot of what we currently "know" to be true about how JS emulates "classes" with function.prototype. I tried to find good citations for this fact, but I'm having trouble finding good "early JavaScript" history. I do know that at least as early as ES1, in mid-1997, we had constructors with prototypes and "new". [1] In any case, besides `Object.create()` which you've noted, here are some other milestones in the evolution of "OO in JS" I could find: `instanceof` was added in JavaScript 1.4 [2], which was sometime after Oct 1998 [3], probably officially in ES3. `Object#isPrototypeOf()` was added in ES3 [4], which was around late 1999. `Object.getPrototypeOf()` was added in ES5 [5], which was around 2009. [1] http://www.ecma-international.org/publications/files/ECMA-ST-ARCH/ECMA-262,%201st%20edition,%20June%201997.pdf http://www.ecma-international.org/publications/files/ECMA-ST... [2] https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Operators/instanceof https://developer.mozilla.org/en-US/docs/JavaScript/Referenc... [3] http://en.wikipedia.org/wiki/Javascript#Version_history http://en.wikipedia.org/wiki/Javascript#Version_history [4] https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Object/isPrototypeOf https://developer.mozilla.org/en-US/docs/JavaScript/Referenc... [5] https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Object/getPrototypeOf https://developer.mozilla.org/en-US/docs/JavaScript/Referenc...

_getify 13y ago

In part 2, which should be published today, I'll be addressing "class { }" and why I think it doesn't belong in JS. I think it's just more "distraction" that moves us away from a better clearer understanding of how [[Prototype]] behavior delegation works.