Comments on Meeting Notes

John J Barton johnjbarton at johnjbarton.com
Wed Dec 5 10:43:40 PST 2012


On Tue, Dec 4, 2012 at 1:28 PM, Brendan Eich <brendan at mozilla.org> wrote:

> Mark S. Miller wrote:
>
>> On Tue, Dec 4, 2012 at 10:48 AM, Brendan Eich<brendan at mozilla.org>
>>  wrote:
>>
>>> Kevin Smith wrote:
>>>
>>>> I recommend allowing let declarations only in strict mode.  This is the
>>>> simple, backwards-compatible path.  Strict mode only has a bad
>>>> reputation
>>>> because, in ES5, it is restrictive-only.  There are (almost) no carrots
>>>> leading users there.
>>>>
>>> Strict mode has a bad rep for two other important causes:
>>>
>>> * It forks runtime semantics, which requires careful testing in
>>> pre-ES5-strict implementations. This has been a real-world problem,
>>> multiple
>>> times.
>>>
>>
>> I buy this for old code that needs to just keep working, bugs and all,
>> without human attention. But strict mode can be opted into
>> incrementally, per program or even per function.
>>
>
> Real world problem: concatenation.


By reaching out to the few concatenation engines it might be possible to
reduce this problem in practice.


> > From what was said at the TC39 meeting, the main "cost" is simply that
> strict mode has a bad rep with the community. This bad rep, to the
> extent it still exists, is largely superstition.
>

I suggest an alternative analysis: developers likely to adopt 'use strict'
are likely to know of its benefits. They are unlikely to realize
significant benefits exactly because they are aware of the pitfalls the
feature prevents. Thus when they become aware of the costs (cited by
Brendan), their cost/benefit flips easily to the other side.  Thus
use-strict-deniers are not 'superstitious': only zealots stick to a
technology after the cost/benefit gets out of whack.  Mitigating the costs
is important to improve adoption.

jjb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121205/367a0d4f/attachment-0001.html>


More information about the es-discuss mailing list