Wouldn't being bolder on new constructs save the "breaking the web" costs for future"?

Brendan Eich brendan at mozilla.com
Tue Jan 8 03:48:35 PST 2013


You are describing path dependency, which afflicts us all, in various 
evolving systems including JS.

We cannot keep resetting ES6 to include and think through and make 
consistent things such as nil. Sorry, that trades off badly against 
developers' time -- they need the good stuff coming already in top 
engines, which Allen is drafting.

Of course we have strawman: space on the wiki, and I'm going to work on 
existential operators and possibly nil there, for inclusion in Harmony 
(whatever edition that might be).

And since we're only human, along the dependent paths we walk, missteps 
happen. If we can back up and take a better path in time for ES6, we will.

Another thing we try to do: make incremental progress edition by 
edition, based on experience ("pave the cowpaths", lessons from nearby 
languages, championed designs that are prototyped early, e.g. proxies), 
but not close important doors. This is called future-proofing.

Your desire to make class object identity !== class constructor function 
identity could be viewed as future-proofing, but we have to pick some 
identity for ES6. And again, apart from the need to separate constructor 
invocation via () from invocation view new, we don't have strong 
motivation to future-proof.

It's easy to wrap up your own designs along neater lines that themselves 
have lots of dependencies (nil in language is controversial, from my 
twitter survey -- it arguably hides errors). Mature language design, 
really all successful language design however radical, shies away from 
running ahead along one path too far, at least in the "main line". That 
would be ECMA-262, so ES6 ;-).

/be


More information about the es-discuss mailing list