> 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