My ECMAScript 7 wishlist | Hacker News Reader

My ECMAScript 7 wishlist

nczonline.net

39 pointsradmuzom48 comments

Shameless plug, but the author should check out Dart.

Dart's core libraries include first, last, isEmpty, isNotEmpty getters for Iterables, as well as a ton of functional methods like map(), where(), reduce(), expand() (flatMap). Not only do the built-in Lists implement Iterable, but so do NodeList, so you can do things like:

  var e = query('#id').children.first;

Dart's annotations would serve as custom property descriptors, and mixins are like traits. Having interfaces in general is also hugely beneficial.

It also sounds like he leans towards wanting closed classes with your requests for deepSeal and defensive classes. This does prevent a lot of errors. Both Dart and TypeScript give you this type of safety.

Good points, but given the author is one of the most well known JavaScript engineers in existence today - I guess that it is highly likely that he has already checked them out.

Dart is a Google proprietary product.

Its neither proprietary in the sense of closed implementation or in the sense of not having an open, freely implementable spec. Its "proprietary" only in the sense of "not adopted by a standards body".

Not adopted by a standards body is a pretty significant factor.

It is also proprietary in that Google is in absolute control of the development process.

I think anyone can participate in the ECMA TC52 meetings.

I'm not sure about membership in ECMA, I think there other requirements.

There appears to be no activity or information about this process that is publicly available.

That's a very legitimate complaint. Gilad Bracha sometimes posts updates[1] to the Dart mailing lists, but I'm not familiar with ECMA, or if it has a standard way of posting information and updates about technical committee work.

I'll raise it with the team and see if we can have a place to post upcoming meetings, agendas, minutes, and decisions and draft specifications. It'd also be nice to have a way, besides the issue tracker (which like all issue trackers can seem like a black hole for issues for some people) to propose items for upcoming meetings. I find Python's PEP to be a pretty nice system.

[1]: https://groups.google.com/a/dartlang.org/forum/#!searchin/mi...

Pretty significant factor in what? Write down all the reasonably popular programming languages you can think of. How many have been adopted by a standards body? How many have been adopted by a standards body in their current form?

I hardly ever write code in a standardized language. Actually, I don't think I know anyone who writes code in a standardized language, because nontrivial programs in "standardized" languages almost always go outside the strict confines of whatever mediocre crap some committee adopted.

C, C++, JavaScript, Java, Fortran

Only the vast majority of all commercial code ever written.

Those are all examples of languages that started off as proprietary, just like Dart.

You've just proven my point while cleverly but unsuccessfully trying to avoid being responsive to my inquiry. Java was never adopted in any form by a standards body, three of the remaining four are an already-small and ever-shrinking share of the industry, and ECMAScript is never up to date with the latest developments in JavaScript.

Even if you are right, and I'd only grant you that I am partially wrong about java because the JCP has collapsed since the Oracle takeover - the rest are just you adding qualifiers to minimize the contradiction, so what?

Your position is simply to dismiss the value of standards and state that it's fine that Dart is proprietary.

Also your statement about ECMAScript is flat out disingenuous. JavaScript implementations may move ahead between ECMAScript standards, but it is standardized, and by a real cross-industry group, not just a rubber stamp from one company.

It is hard to take seriously an assertion that the level of standardization between Dart and JavaScript is comparable.

Nobody made that assertion. You made an assertion that standardization is "a pretty significant factor". You've yet to clarify what it's a significant factor in, nor have you provided evidence that it is, in fact, significant.

I also didn't state that it's fine that Dart is proprietary, and I'd appreciate you not putting words in my mouth. My position is that your premise is incorrect and Dart is not proprietary.

Well, we have ECMA TC52 which will hopefully ratify the specification pretty soon.

But proprietary in the sense of that there is only one implementation and it is maintained by one company (Google).

It's always available to be forked. By the same standards, Ubuntu is proprietary, as is Firefox.

A forked programming language is no longer the same language.

That's not a big deal. Browsers are in a desperate need for a non-transpiled client-side language competition.

It's the lack of competition that makes it a problem.

There aren't that many languages that aren't "proprietary" in some way or another at their beginnings. C, Java, JavaScript, Rust, Go, Swift, Python, Perl, Ruby, Clojure, TypeScript... on and on.

Haskell is one of the few modern languages I know of where a language was birthed in committee. ALGOL and COBOL are some older examples.

The already said ES6 spec will be delayed again, this time for June 2015.

So it will take until like 2020 to be able to use it without transpilers and hacks for all the non supporting browsers (most of them).

So I don't have any ES7 wishes. Until then who knows even if I'll still be doing web front-end work.

I think it would be a safe bet to wish that ES7 has a better support of second generation quantum computation primitives and a good implementation of exocortex interoperability APIs.

I think allowing the negative array index, like "items[-1]", would greatly improve the indexing problem. IIRC, JS strings also don't support negative indexes. Is this intended? I think the backward incompatibility that would be led by the change should be tolerable.

And to my personal preferences, I prefer "items[0]" to "items.first()", though the latter is more "english". One of the comments from the post also suggests "items.slice(-1)[0]" as a replacement of "items.last()", but that's another case...

That would break backwards-compatibility, however. Arrays are just objects with a magic .length property. As such, I can already do `items[-1] = 'foo';` and it'll create a property named "-1" and set it to "foo".

Yeah, that's what I wanted to say by the "tolerable" part. I know arrays, as well as other plain objects in JS, are capable of having arbitrary properties. But hey, how many libraries or code rely on that specific behavior of Array? For the "Greater Good", they can suppress those minor cases and simply extend the magic to the negative integer range. I believe this change can be landed without too much compatibility pain.

Putting arbitrary properties on an Array, in practice, turns it into a hashtable or a 'mixed' hashtable+Array (this depends on the JS implementation.

Dense array layouts are largely an optimization that the JS runtime applies if it's able to. So you 'can' put arbitrary properties on an Array, but you risk throwing away the benefits you get from using it instead of Object.

Sadly the risk of compatibility pain is huge for almost every change you can possibly imagine. I've been participating on es-discuss for a couple years now and tiny, harmless changes end up breaking real web applications on a regular basis - causing the spec committee to have to scratch their heads and figure out a fix. Sometimes there isn't a fix, and they have to rethink.

Can't the exception throwing on missing property behaviour be created using ES6 proxies?

Anyway, while many of these things would be nice additions, I think ES7 will contain more low-level features which particularly benefit libraries and compile-to-js languages, such as SIMD support and value objects. Personally, I'd love to see tail call elimination in the spec.

It appears the author has already answered my question:

http://www.nczonline.net/blog/2014/04/22/creating-defensive-...

Interesting how this author uses WeakSet where a normal set would be completely equivalent; as long as the function is running, the toplevel object is reachable from the local variables, and so are all the "deep" objects, by definition (they belong to the toplevel object's reference graph). Therefore, there is no way that an object becomes unreachable after it has been visited by the algorithm (considering that JavaScript is single-threaded). The only reason I can see for this is if JavaScript has no normal sets.

JS has Set and WeakSet, and Set is more powerful (it allows a wider variety of key types). It's actually quite rare for you to need a WeakSet.

On the other side of the spectrum, what improvements could be added to JavaScript the assembly language to make it easier and more efficient to target to ?

They want everyone to think same way and use one single multi-purpose scripting language. JS as a bytecode is a less favourable outcome for them for some reason, maybe because everyone would stop caring about using JS directly. Hence the unfortunate lack of news on the asm.js side.

If by 'lack of news' you mean 'active development and more tools vendors introducing asm.js targets', sure. asm.js support keeps improving in all the major browsers, while Epic and Unity both have increasingly viable asm.js+WebGL backends. Furthermore, emscripten is moving towards being a mature LLVM backend instead of a separate compiler tool, and other compilers are adopting asm as well.

Better things to wish for:

- async / promise / await

- object merging / cloning (with options / deep)

- array properties instead of methods (ruby style, array.first, array.last, array.empty, array.contains, etc...)

- lets not forget other object types that need methods, Number, Boolean, String (.equals, .equalsIgnoreCase, etc...)

Let's just say, javascript could be a lot better :P

The author complains about having to type "items[items.length - 1]" a bunch but then shows how to implement last() and first() himself very easily via prototyping 6 lines of code onto Array.

So... what is the problem again?

(a lot of the other stuff in the article is valid though)

Extending a browser provided prototype shouldn't be done lightly. You certainly couldn't do something like that if you were writing a library, as you might conflict with somebody elses implementation of the same add on.

There's also value in having things like this standardized. If its a common idiom, its worth including in the standard to allow people to use it without having to worry about what utility libraries they're including.

I actually tend to think that this kind of shows the folly of single-dispatch OO in general (prototypical or not), in particular its focus on privileging the first parameter syntactically. The problem here is essentially that a freestanding function looks and thus (subjectively) "feels" different from a method. The syntax is obviously slightly different: "myArray.last()" vs. "last(myArray)". The latter stands out as slightly "alien" when compared to the other methods on Array.

Why should the first parameter be privileged? Why isn't it possible to add a new method to, say, Array which is scoped to your lexical context?

Even classic procedural programming didn't have this problem (as long as you don't need access to private data): Just add a function that does what you want and it'll look and behave just as the other functions on Array.

EDIT: Maybe the focus shouldn't be on adding a few convenience methods here and there, but rather on making the language itself more "pliable" or "growable" as Steele would probably say.

Nothing prevents you from using a function (`last(myArray)`). In a dynamically typed language what you are proposing makes only very limited sense.

I'm not saying functions are bad or anything. They just "feel" wrong since they don't look like the built-ins.

Regarding "dynamically typed": CLOS[1] got this right. Common Lisp is dynamically typed. In short: Dynamic/static typing has very little to do with this.

[1] http://en.wikipedia.org/wiki/Common_Lisp_Object_System

scoped monkey would be quite usefull? One could mess with prototypes yet keep them clean in the global scope.

last(array) feels to much like C style OOP.

I agree. C# has this feature. They call them extension methods. They alive the scoping issue quite nicely: http://msdn.microsoft.com/en-us/library/bb383977.aspx

They should just provide an operator like ::, then features that can be implemented without special language support don't need to bloat the spec.

    array::last()

would mean same as

    last.call(array)

that means `last` can just be a regular variable in scope

All valid points but there are ways that you can implement prototypes safely (even in the presence of other utility frameworks that might implement their own version), or use one of the many other ways JavaScript provides you for.

Not having to ever talk about it again. Not having to teach people that monkey-patching global prototypes is a good practice. Having a standard feature would encourage other array-like interfaces (e.g. NodeList) to add the same methods.

These are all pretty minor things that can already be done in ES5.... The biggest thing I want in ES7 is immutables.

Thanks for the article. I agree with most of this, however for empty arrays I find it best just to check length in the "falsy" way. Like -

if ( !array.length ) { //do something }

Seems succinct enough not to require a separate function.

if (array && !array.length) { /* do something here */ }

Check existence as well, this also works for a jQuery selection.

Reply on news.ycombinator.com