excluding features from sloppy mode

Kevin Smith khs4473 at gmail.com
Sat Dec 29 21:33:46 PST 2012

> 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 }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121230/bd213591/attachment.html>

More information about the es-discuss mailing list