The few number of changes speaks of the already inherent quality of the language.
ECMAScript 2016 Approved
41–50 of 83 posts
Re: ECMAScript 2016 Approved
#42They 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.
But all libraries had their own implementation of createClass, the idea was to pave a cow path that was already there, not to invent some completely new pattern.
Re: ECMAScript 2016 Approved
#43They 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 often worry that with every new standard the platform becomes more opaque for newcomers. You know, average people who want a shot at making their own webpage and learn to program for something with an immediate use case.
It's not like you have choices of language on the web, the JS jungle is intimidating enough for newbies as it is. I know many will tout compile-to-js as the solution, but that's an even higher barrier to entry and you get too-much-choice syndrome.
Not that I haven't been glad with the ES6 additions myself ...
Re: ECMAScript 2016 Approved
#44They 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 often worry that with every new standard the platform becomes more opaque for newcomers. You know, average people who want a shot at making their own webpage and learn to program for something with an immediate use case. It's not like you have choices of language on the web, the JS jungle is intimidating enough for newbies as it is. I know many will tout compile-to-js as the solution, but that's an even higher barr…
AFAIK JS is almost completely backwards-compatible. Just ignore all the new stuff you don't really need and focus on the basics.
Re: ECMAScript 2016 Approved
#45Earlier 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're confusing a language with a platform. The language specs of the languages you mentioned do not have file system semantics included
I'm not confusing anything here. Unless a language has a platform specific API it typically gets bundled into the language specifications itself to ensure consistent interfaces and to force implementations to match a set standard.
C++'s STL is part of its specification. Python has a library reference outlining the interfaces their standard libraries must include.
You're still thinking in browser world. In a browser world a browser is a platform and has to provide APIs to allow JavaScript to interact with its elements. Today this isn't always true. Today you have node.js and several other execution engines that allow JavaScript to run anywhere much like other languages. It's time the standard reflects that new reality, in my opinion.
Re: ECMAScript 2016 Approved
#46Earlier 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
Which is wrong. As is the use of "absolutely" - to show that you have the universe-opinion. What hubris. And it does not matter that some guy "himself" posted some opinion either. Right were you link to there are different opinions from other people that show more thought was put into them. The "pg" comment actually is the only one for your argument, all others are against!
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 silly. Relatedly, you might be interested to note that there are dozens of HN old-timers that will automatically downvote (nearly) any comment that contains a "downvote me if you want" or a "don't just downvote me if you disagree" or "these downvotes are BS" or something.
You're right, though, that not all users agree. And hopefully you learn from this comment that it's okay, on HN, to downvote me if you disagree, even if you think I contributed to the conversation.
PS: welcome to HN.
Re: ECMAScript 2016 Approved
#47Earlier 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
Which is wrong. As is the use of "absolutely" - to show that you have the universe-opinion. What hubris. And it does not matter that some guy "himself" posted some opinion either. Right were you link to there are different opinions from other people that show more thought was put into them. The "pg" comment actually is the only one for your argument, all others are against!
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.
Re: ECMAScript 2016 Approved
#48So, ECMAScript 2015 is ES6 and ECMAScript 2016 (this) is ES7 [0]. I like the new features (promises, arrow functions etc.) but the naming is as confusing as Visual Studio. VS 2015 is the current version but VS 15 is the next one.
Re: ECMAScript 2016 Approved
#49Earlier quoted context omitted.
Which is wrong. As is the use of "absolutely" - to show that you have the universe-opinion. What hubris. And it does not matter that some guy "himself" posted some opinion either. Right were you link to there are different opinions from other people that show more thought was put into them. The "pg" comment actually is the only one for your argument, all others are against!
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…
[deleted]
Re: ECMAScript 2016 Approved
#50Earlier 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…
> wouldn't it make more sense that the environments supply what's meaningful on top of a very light base
I certainly don't think so. JavaScript is a language that works in more places now; commonized libraries would be a huge benefit. As an example you wouldn't use Python with different io libraries depending on the operating system it's running on and yet this is what node is evolving into.
> Like window.document.querySelectorAll in browser and require("fs") in node.js?
querySelector / querySelectorAll are specific to a browser platform but a way to conduct io could be pretty universal, in my opinion.