Live data from Hacker News

ECMAScript 2016 Approved

ecma-international.org

71–80 of 83 posts

Re: ECMAScript 2016 Approved

#71
post #38

They should be working to make JS smaller and simpler and better. Focus on the philosophy of what JS should be. People instead tend to focus on 'new features'. The power in JS is functional programming. For instance, grafting on Classes, was a mistake. They may focus on concepts like, how do we make sure we never create two ways to do the same thing - instead of how do we incorporate this new thing.

I think the way they added classes was actually ingenious. I actually don't use classes or even prototypical inheritance, I only use functions, functions and functions. But they didn't really change Javascript at all under the hood as far as "class" support is concerned apart from some minor things at the edges - it's the exact same prototypical inheritance pattern as before, only that you write it differently. And i…

What is your programming background? I just wondering because I also do not use classes or even prototypical inheritance but just functions. But I did not come from a class-heavy background like Java. I'd like to see a poll of those who use classes vs not in JavaScript and whether they come from a class-heavy language background (like Java) or not. My assumption is that those who come from Java prefer to use classes in JS and others not so much.

Re: ECMAScript 2016 Approved

#72

I wish this contained a delta between the previous release and this release. It's difficult to find the differences just by skimming. Edit: apparently I hadn't realized that the changes were so few that what was in the outline really did cover everything. I thought it was a summation. My fault. That being said I continue to be disappointed in the built-in standard library of JavaScript. As far as I can tell ECMAScrip…

But, wouldn't including file IO in JS lead to massive security problems in the browser?

Re: ECMAScript 2016 Approved

#74
post #32

Earlier quoted context omitted.

> Javascript isn't python or c. It's more like Lua: It's meant to be embedded inside an application, and the application provides all the interfaces you need. I couldn't disagree more. JavaScript started out that way but today (really the past 6+ years) it's used in identical use cases as Python in addition to being embedded into web browsers. > If you start trying to include things like file i/o in the base language…

> You don't need to. Provide the basic capabilities that all languages provide, restrict what isn't possible when it's embedded into an environment. Keep it simple. Well, that makes sense but wouldn't it make more sense that the environments supply what's meaningful on top of a very light base? Like window.document.querySelectorAll in browser and require("fs") in node.js? I, although, also think that stuff like what…

That would seem sensible: just a native `range` function would be nice, and more declarative methods available natively would be great (zip would be very useful). Having primitives to build upon is pretty important though: I don't know of the Observable proposal is the best to pick on, given its general usefulness for UI

Re: ECMAScript 2016 Approved

#75

Earlier quoted context omitted.

Well given that it's PG's site, I'd say his opinion is the only one that matters. Besides, votes are used for agreement more than for any other purpose, and given that there's no way to force people to not do this, let's just dispense with the fiction that they can ever mean anything else. "Please no downvote" is just noise.

Horsehit - mass opinion obviously matters a lot more on this subject, since there is no way to enforce our arbitrary kowtowing to Paul Graham's wisdom. What is he going to do, yell at us for down voting incorrectly? This is our website. Maybe pg 'made' it, but we use it. If most of us disagree that is what will (and should in my opinion) happen.

>What is he going to do, yell at us for down voting incorrectly

He can always close down the side.

Besides, it's not about "what is he going to do" -- it's about what people coming here should respect.

Re: ECMAScript 2016 Approved

#76
post #46

Earlier quoted context omitted.

pg wrote the site, pg is one of the owners of the site, pg was the only admin at the time that that comment was written. Admins/maintainers (dang) since then haven't disagreed. That makes it site policy, doesn't it? When you come to a new site, it's usually considered civil to learn the rules of that site, although of course I cannot force you to do so. For example, assuming that reddit rules apply on HN is kinda sil…

> pg wrote the site What does ownership have to do with it? That does not make him more right than any other human being. Ownership means one can impose ones will, it does not mean you are omniscient.

>That does not make him more right than any other human being.

No, just the only relevant person to say what is welcome and allowed in HIS social bookmarking forum and what's not.

>Ownership means one can impose ones will, it does not mean you are omniscient.

"House rules" are not meant to be perfect or agreeable to all -- they are just meant to be whatever those running and owing the house decide.

Re: ECMAScript 2016 Approved

#77
post #30

"This specification also includes support for a new exponentiation operator and adds a new method to Array.prototype called includes." Not much new here for regular JavaScript developers.

Everything about this is for regular JS developers:

Exponentiation operator:

    2 ** 32
is much friendlier to write than Math.pow(2, 32) or

    x **= 2
versus x = Math.pow(x, 32).

Array.prototype.includes: if (['jim', 'bob', 'dave'].includes('bob')) { console.log('We have a party, now.') } versus using for/in, for/of, map/reduce or much more commonly importing JQuery/Underscore/Lodash/some other random npm package for this functionality.

Both are small improvements, but both are squarely for "regular JavaScript developers".

Re: ECMAScript 2016 Approved

#78
post #75

Earlier quoted context omitted.

Horsehit - mass opinion obviously matters a lot more on this subject, since there is no way to enforce our arbitrary kowtowing to Paul Graham's wisdom. What is he going to do, yell at us for down voting incorrectly? This is our website. Maybe pg 'made' it, but we use it. If most of us disagree that is what will (and should in my opinion) happen.

> What is he going to do, yell at us for down voting incorrectly He can always close down the side. Besides, it's not about "what is he going to do" -- it's about what people coming here should respect.

He could, but it's unlikely he will close the site over improper downvoting behavior (which is rampant, but unimportant). And what I think people here should (and do) respect is the general spirit of civility; we respect Paul Graham's wishes because he asked for civility, not vice-versa. If Paul Graham asked us to be pointlessly cruel, we would not respect that (or we would be congregating elsewhere).

Therefore, what matters most in practice is the mass opinion of users of the site - what do we think is most useful and respectful in daily usage (following Paul Graham's lead to be respectful because we can all agree that this is a good idea).

Re: ECMAScript 2016 Approved

#79
post #34
post #24

Earlier quoted context omitted.

> Please don't downvote parent if you disagree with parent's opinion, downvote only if it doesn't contribute to the discussion You are wrong. It's absolutely fine to downvote on disagreement. See the following comment from pg himself: http://news.ycombinator.com/item?id=117171

The irony of your post getting downvoted is delightful. (I myself agree with you.)

also ironic: it's my highest scored comment ever.

Re: ECMAScript 2016 Approved

#80
post #9

Earlier quoted context omitted.

I can't find anything related to it. It's literally the only feature I use in ES7, so I hope it is in there. Perhaps it has some other obscure name?

Decorators are not an ES7 feature. They are a stage 1 proposal, which means roughly that the committee agrees this problem space is interesting, but that it might see drastic changes in implementation, syntax, and more, or might not make it into the eventual standard at all. At this point it is best to call them a Babel feature, not an ES feature.

I do hope they gain some more traction. I've found them to be very useful with reducing boilerplate / repetitive code.
Post reply on HN