Mark S. Miller wrote:
On Wed, Dec 26, 2012 at 2:58 PM, Brendan Eich<[email protected]> wrote:
Mark, you cite some issues we need to work through, but opt-in via pragma
syntax beyond "use strict" is not one of them.
Sorry for the confusion. As I just clarified in my response to Dave, I
am not suggesting any of those previous MIME type or additional pragma
ideas. I am just suggesting that we stop twisting the language to try
to fit ES6 features into non-strict mode when these don't fit well.
Your subject was a declarative sentence, past tense, not a suggestion!
It also meant other than what you clarified.
Ok, I don't mean to vent -- moving right along:
What's more, the big-picture claim in your Subject line ("has failed"
especially) is not true. In an overriding sense, 1JS can't fail, because
versioning is an anti-pattern (or at best retrospective, not prescriptive)
on the web. To be more precise, ES6 will fail if it requires opt-in
versioning apart from the new syntax itself.
I am not suggesting any new opt-in beyond what we've already got. I am
suggesting that we use that opt-in, rather than contort the language
for the sake of non-strict mode. We all know that the non-strict mode
of JavaScript can never grow into a decent language. As you've long
said about the arguments object, let's stop polishing this turd.
But it's not the same turd. Rest parameters combined with destructuring
and default parameters can do more than arguments could do, and
crucially do so via new syntax. There's no comparison to function in
block, which syntax already exists in the de-facto standard, whose
meaning ES6 proposes to change.
Let's move away from feces metaphors :-|.
The major issue I see outstanding between us is that the economics of
strict mode as faced by most developers must be considered, on top of
the desirability of the feature that doesn't fit in sloppy mode.
This is a human factors problem in part. We should do quantitative
studies. I just asked in re: Brian's head post whether his crawl checked
for "use strict" usage. Another thing we could try: for the 4% of
scripts used by the 2235 sites crawled that use funciton-in-block, how
many can "use strict" without any revision?
The economics of strict mode is subject to pedagogy, better
optimizations for strict code over time, and the death of pre-ES5-strict
browsers over time, too. So again I'm not beating up on strict mode. But
I do think we must look at the thing in the field, including its human
factors, and not just say "use strict" always, be happy. It's not always
an option in large projects or even small ones using libraries that
aren't strict-ready. More below.
This applies to "use strict"
too, since it has costs (both performance and semantic changes that double
testing while old browsers are in the field).
I thought we'd settled the performance issue. I'm surprised you're
still raising it.
It's not quite superstition. Look at the strict vs. non-strict
differences in the charts for these three:
http://jsperf.com/calling-into-strict
http://jsperf.com/use-strict-vs-array/2
http://jsperf.com/use-strict-vs-array/3
In theory, apart from freakish cases involving arguments objects and
parameter aliasing, strict mode should not be a performance penalty and
could even help. In practice we aren't there yet -- and developers know
this.
The purpose of testing is to alert you to places in your code where
bugs may reside. Even if you never plan to run your code in strict
mode, you should still test in strict mode, since anything that fails
in strict mode is likely enough a bug in your code that you should
investigate.
You don't need to tell me!
The problems is the added burden and the inevitable failure of real
developers to take it on with the same diligence they use on one-mode JS
-- which may be less diligence than you would like, but hold that equal!
The testing burden has gone up.
I'm describing, not prescribing. Old pre-strict browsers will die off,
we'll be in a better place. I like strict mode in general and won't
quibble about a few corners here. But the problem isn't my opinion of it
or yours. The problem is that strict mode has meant more to go wrong,
more to test, and some performance faults.
Now, on the specific JSC bug you cite,
https://bugs.webkit.org/show_bug.cgi?id=27226. This is actually from 2009,
filed based on a misunderstanding of ES3 and not on any real-world web
content, and finally marked invalid in February. It is old news. The
comments from February do not prove that "[t]he 1JS experiment has failed".
I was unaware of the history, thanks. I withdraw that bullet point. I
acknowledge that my case is substantially weaker without it.
Ok, thanks.
And JSC design decisions are not authoritative over TC39 as a whole --
rather, the reverse!.
We all know that this issue isn't so unidirectional. If TC39 mandates
something and the browser makers decide to do something else, we all
have a problem. The pressure to avoid these problems cuts both ways.
And how! We've already heard some feedback on temporal dead zones from
one TC39 implementor-rep at the September meeting. I never said
implementor feedback doesn't count, though. Only that the
authority-arrow runs the other way from what your bullet point suggested.
It's pure mischief for implementors to "vote" outside of TC39 by making
random deviations from draft-ES6 on purpose and then asserting precedent
or authority.
I know you didn't endorse that but your citing this bug under the
inflammatory subject was going in that direction.
Anyway, we can certainly make function-in-block ES6 semantics require "use
strict" opt-in, but that will both diminish the use-frequency of
function-in-block with sane and standard semantics,
Since only strict mode provides sane and standard semantics anyway... ;)
and as Andy Wingo
pointed out in the JSC bug, confuse users with two semantics for the same
syntax.
We've already got that. To avoid confusion, "use strict".
That's a prospective, prescriptive, pedagogical approach. It will help
over time, but right now, not so much. Real developers face real code,
most of it non-strict. They can't always afford to make it all strict.
They therefore face the confusing schism in function-in-block semantics
that Andy cited.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
