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.
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".
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.