Wouldn't being bolder on new constructs save the "breaking the web" costs for future"?
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 ;-).
More information about the es-discuss