ES6 opt-in, reloaded

Andreas Rossberg rossberg at
Tue Jan 17 04:53:44 PST 2012

On 17 January 2012 03:12, David Herman <dherman at> wrote:
> The only way to avoid refactoring pitfalls entirely is to avoid making any changes in the language altogether.

I disagree, see my previous reply. It depends on what class of
refactoring pitfalls you are talking about.

> I believe we should do our best to avoid refactoring pitfalls as much as possible, but I can live with a few (e.g., differing scope rules for block-local functions, arguments aliasing, eval scoping, special cases for destructuring + arguments) in exchange for the drastic improvement to developers' cognitive load, the vastly improved adoption story, and the unity of the spec.

I'll repeat a point I've tried to make earlier. Having all (or the
majority of) new features in both classic and extended mode does _not_
decrease cognitive load, nor unity of the spec. That's an illusion
(which, admittedly, may work with developers, but it's cheating on
them). Instead, there are more cases everybody has to worry about.
Language complexity will be _increased_, and "unity of the spec" is
merely a euphemism for having to spec ugly corner cases that you
didn't have to spec otherwise.

Let me put it a different way. One lesson I've learned over years is:

- context-dependent lexical syntax is a bad idea.
- context-dependent grammatical syntax is a bad, bad idea.
- context-dependent static semantics is a bad, bad, bad idea.
- context-dependent dynamic semantics is a bad, bad, bad, bad idea.
- context-dependent library semantics is... well, you get the idea...

There already is enough of that in JS that we cannot get rid of. I'd
prefer not to combinatorially enlarge that set. And the implicit,
scoped opt-in idea is on the 4th level of badness. ;)

And with that, I gonna shut up.


More information about the es-discuss mailing list