Kevin Smith wrote:
This is a bit long - bear with me...
First, let me make one more argument as to why "new syntax, just use
it" won't work:
(a) In ES6, "let" is the preferred way to declare variables. Let's
not be relativistic to the point of goo here. Block-scoped variables
are "better". As such, "let" is of central importance to the language.
(b) ES6 sloppy mode cannot have "let".
That's overstated, and as such it contradicts the tenuous consensus of
the last TC39 meeting: to reserve 'let' contextually in sloppy mode and
evangelize any let [x] = y code out there already (which we've yet to
find -- 'let' is used as an identifier, short for 'letter', but not
indexed into on LHS).
The rest of your reasoning is therefore overstated. It does not follow
if we can reserve 'let' in ES6, mode-free.
(c) Therefore, ES6 sloppy mode is a hobbled, incomplete version of the
ES6 language, and
See above.
(d) Since ES6 sloppy mode is not the same as ES6, there can be no
"1JS" as long as ES6 sloppy mode exists.
Here I want to refine my Platonic prettiness critique. You talk about
ES6 as if it can be a thing, which has a timeless existence and truth
and beauty. Kind of like a dodecahedron -- a pure "Math thing".
I see that, but it's an abstraction. It is not real, it is ideal. In
reality, you might argue the spec approximates this thing, but there are
many problems.
What I think "exists": ES6 as a practical language with a large user
community who apprehend it in pieces, and sometimes using different
metaphors or incomplete and even inconsistent "theories" or schools of
thought. It's a human thing, not a Math thing.
In this light, "1JS" is totally winning. It's a "true myth" as much, or
moreso in my view, as the "use strict and you'll lose the crazy" true-myth.
Sure, you could attack (b) by using parsing tricks and special cases.
We agreed at the last meeting to treat 'let' as a contextual keyword at
start of statement if followed by an Identifier, '{' or '['. That is a
special case, but so what? 'module' was not reserved in ES1-5 so it
needs a special case too.
The spec must serve the users. Not the other way around. Or would you
give up 'module' from sloppy mode?
You can make anything "work". But then we're shirking the language
designer's responsibility of guarding the values of simplicity and
elegance.
These matter a lot but they are rather less well-defined than you make
out here. I think 1JS is simple and elegant, even with other new syntax
than 'module' as its own opt-in. I think I can make that case, and I'm
trying to.
But to continue my point above, the simplicity and elegance, subjective
in many ways, of the "ideal" ES6 must take a back seat to the real ES6,
including its ease of adoption. That's where I think requiring "use
strict"; to use new syntax (other than 'module') hurts more than it helps.
Imagine you are adapting existing code, including popular libraries not
yet in strict mode, to a new app targeting ES6 or better runtimes
directly, and ES5 and older via a compiler such as
https://github.com/matthewrobb/six. You are not yet be ready to "use
strict" in the concatenation of all the code -- there's too much risk of
breaking something, and never enough test coverage.
You want to use ES6 features such as rest parameters and destructuring
right away, before any "use strict" or module wrapping. Under your
proposal, you can't. You have to multiply risks and spend time turning
on strict mode, testing harder in old and new and middling (IE9,
anyone?) browsers.
Why is this a good thing?
Oh sure, in 10 years, no worries. But let's consider that future, which
Andreas and others argue is larger than the past.
In 10 years, you want everyone to use modules, but there'll still be
top-level code, rapid prototyping, and so on. For such programs, you
want everyone to write the old
"use strict";
chestnut, about which StackOverflow misadvises now (and probably will
then :-P) that minifiers can safely remove this "comment"?
Where's the ideal truth and beauty in this
useless-string-expression-statement-as-pragma hack?
I take it that you agree in principle with strict mode. If I
understand correctly, your central argument against "1JS under strict"
is that:
(a) Strict mode is not popular.
No, I said it's not widely adopted and I've chosen my words carefully.
Re-read my last few messages. It will take time to win everyone over,
and even then the Law of Least Effort says it will be left out now and
then, forever. Nothing on track for Harmony will insist on it as a
shibboleth that must be uttered in some future, say ES8.
So it will be left out, and not every program is a module.
I really don't think I've been unclear about this. In particular I don't
think I used popularity as some kind of static construct, ever. I've
argued about slow (many years) adoption, which is an empirical fact.
I've argued based on the design of the pseudo-pragma itself, that it
tends to be left out. I've therefore argued against multiplying risks.
That's it.
(b) If ES6 syntax is strict-only, then ES6 may well be unpopular.
Not quite. This is where I think a reductio ad absurdum has been put in
my mouth. I never wrote that people will say "ES6, yay! Wait, I have to
hassle with strict mode enabling?" and ES6 will suffer. That's too simple.
Yes, some people will bitch. They are probably mostly the same folks who
will not want ES6 anyway, but a few would be open to what I propose: new
syntax as its own opt-in (and with strict bodies, where there are code
bodies). But let's leave them aside for a minute.
The problem I see is rather the permanent requirement for the "use
strict"; shibboleth, and the ritual spanking one will get when
forgetting to utter it up front before using any ES6 feature, however
lovely and useful in a legacy or mixed codebase.
Again, why?
To preserve some idea based on your economics for simplicity and
elegance but not mine? We could perhaps try to unify how we count these
goods. But I think we should first try to get on the same real,
as-used-in-practice, developer-facing terrain I'm arguing trumps
whatever Platonic ideal we might (and probably do) share.
So why is strict mode not popular? The answer is quite simple:
there's no carrot. It limits the user (in good ways, of course)
without providing any additional power to offset those limitations.
ES6, built exclusively on top of strict mode, provides those missing
carrots.
There's no carrot and there are a few sticks, which are going away but
not yet gone (performance faults, concatenation hazards, downrev
browsers up to IE9 still in the field). Don't forget the sticks in the
"short run".
But even in the longer run, with no sticks, ask yourself: "why am I
requiring all users of new post-ES5 syntax, which could be a lot (future
larger than past) to utter some silly string constant expression
statement to use the new syntax, except for 'module', maybe?"
I see no simplicity and less elegance in making such a permanet
requirement for "use strict".
If we want more strict code sooner, let's make all the new
code-body-bearing syntax in ES6 strict by fiat.
If that's the case, then why are some users vehemently anti-strict?
Opinions vary on all sorts of things. Your argument here is off target.
*My* argumet is not about popularity or fickle developers. It is about
the cost of "use strict" in itself, and its risks gratuitously
multiplying to reduce the odds of good ES6 adoption experience and
long-run ES6, ES7, ES8, and (I hope not) ES9 truth and beauty.
In other words, I'm arguing about better design, both in terms of
intrinsic expressiveness and in terms of human factors. I don't think
"use strict" is expressive or usable in the large, or at least not any
more so than 'module' wrapping or (my position) 'class' or other body
form (generators, arrows) wrapping.
Pseudo-pragma vs. new syntax with strict-by-definition body -- this is a
no-brainer for me. But I don't have a particular "use strict"; adoption
axe to grind. I want more strict code, sooner, with less ugly
boilerplate and potential for painful adoption.
As you've stated, javascript is a big tent with many loud voices
inside. It doesn't matter *how* the language evolves, there are going
to be users on soapboxes proclaiming that "standards bodies suck" or
shouting other blustery provocations. Change always creates winners
and losers. But the language must evolve nevertheless.
Nothing here is at issue, this is off target. Let's get back to the
design issue.
What would convince you that strict-mode would not present a problem
for ES6 adoption, if ES6 syntax were strict-only?
Obviously, if "use strict" were much more rapidly adopted, not
necessarily majority by large-survey counts (github, web crawls) but
trending up toward that end in a way that would be hard to reverse.
Other than that, you have to go back and actually engage my arguments. I
do not have as an axiom that strict-mode opt-in via "use strict" is a
good in itself. It is a means to an end. There are other means,
apparently we even agree on one ('module' wrapping).
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
