> Ease of teaching != successfully imparted knowledge at scale. Sorry, but
> it's true. People don't use "use strict"; at top level enough, and teaching
> them all will take time. Even then, because of the Law of Least Effort,
> it'll be left out.
>
> This is the major objection some of us keep raising, and you don't engage
> with it. Please do!
Sure - my answer is: modules, classes, arrows, and templates. Those
carrots are so sweet that no developer will be able to resist them. I tend
to overstate, I know, but they are game-changers!
> - It creates a clean, linear evolution for javascript syntax: ES3 > ES5
>> strict > ES6 > ES7.
>>
>
> I would use < for that relation, but it's not a subset relation due to the
> non-early-error, runtime-semantic-shifts of ES5 strict.
>
Yep - should have been "<", and it's loose as you say.
> Also, enough pretty (if inaccurate) diagrams! User-facing complexity,
> developer ergonomics, usability matter more than Platonic prettiness.
> There, I said it :-P.
Yep - elegance is my siren song. But if there is a place for Platonic
prettiness, then it must be in the language itself.
> - It eliminates the so-called "micro-modes" in function heads.
>>
>
> A canard, or at most a quibble about banning duplicate formals in the
> present of destructuring, which I am prepared to negotiate away. Please
> don't repeat it carelessly.
Fair enough.
> - It gets everyone moving in the same direction: strict mode.
>>
>
> In your dreams, but in reality the sprawl is large and in several
> direction.
Well, my take is that people just like to talk tough.
> - It eliminates subjective questions about what constructs should be
>> implicitly strict.
>>
>
> There's nothing subjective about such questions, any more than your
> contentions about strict mode being objective. In practice people will not
> use strict when they might, and making ES6 features available only under
> "use strict" will, ceteris paribus, lead to less adoption of ES6 than
> otherwise.
Again, the sweetness of the carrots tell me otherwise.
> and breaking changes (where possible)
>
> Why the "(where possible)"?
>
Because not being a runtime implementor (not yet anyway), I can't comment
on where it might be impractical to have bifurcated semantics.
If you believe in strict mode so strongly, why not make all new syntax with
> a body-form be implicitly strict in that body's code?
>
Platonic prettiness : )
> 2) Modules and only modules are implicitly strict.
>>
>
> Whew! You seemed to throw this out in your lede, really till here.
Modules are the lynchpin!
I know, you're tired of hearing from me.
>
Are you kidding? Not one bit!
> I'll subside for a while. However, you know there are issues with strict
> mode, not all "superstition". Ignoring them, pretending they do not hamper
> adoption, dodges the central objection to your proposal: that by yoking ES6
> feature adoption to strict mode adoption, you multiply risks and reduce ES6
> adoption.
>
I understand the concern, really. But I would say that given the sweetness
of the carrots, it rather eliminates the risk of strict mode non-adoption.
{ Kevin }
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
