Re: Observable GC

[Mark S. Miller]

On Fri, Oct 20, 2017 at 10:52 AM, Filip Pizlo  wrote:

>
>
> On Oct 20, 2017, at 10:29 AM, Mark Miller  wrote:
>
> There is a glaring inconsistency in the criteria we use to evaluate these
> issues. While we are understandably reluctant to admit more non-determinism
> into the platform via weakrefs, we have admitted an astonishingly greater
> degree of non-determinism into the platform via "Shared Array Buffers"
> (SAB), i.e., shared memory multithreading with data races.
>
> The scenario we legitimately fear for weakrefs: A developer writes code
> that is not correct according to the weakref specification but happens to
> work on present implementations. Perhaps it relies on something being
> collected that is not guaranteed to be collected.
>
>
> Being collected when it shouldn’t have been?  Like a dangling reference.
> The game theory of security exploits forces implementations to keep things
> alive longer, not shorter.
>

Not what I meant. Being collected when it should not be would clearly
violate the spec. Rather, the weakref spec never guarantees that anything
is collected. Any program whose correct behavior ever relies on anything
being observably collected is an incorrect program. When run on a different
correct implementation --- one on which those objects never get observably
collected --- it will misbehave.




>
> Perhaps it relies on something not being collected that is not guaranteed
> not to be collected. A later correct change to an implementation, or
> another correct implementation, causes that code to break. The game theory
> punishes the correct implementation rather than the incorrect code.
>
>
> Java had weak refs and multiple different implementations.  My claim, as
> someone who implemented lots of weird GC algorithms in Java, is that I
> don’t know of a case where different weak ref semantics breaks something.
> The only time that getting it wrong ever had an observably bad effect is
> when you break weak refs or finalizers so badly that they never get cleared
> or called, and then some resource has an unbounded leak.  This usually
> results in not being able to run any benchmarks that have weak references
> or finalizers, so you fix those bugs pretty quickly.
>
> Here are the motivations:
> - Competitive perf motivates GC authors to try to free things as soon as
> possible.  Smaller heaps mean more speed.  Some benchmarks won’t run to
> completion if you aren’t aggressive enough.
>

This causes only a tendency to collect more as a quality-of-implementation
issue. And even for that, it is at best a statistical issue. There is never
a guarantee that anything in particular will get collected.

- The need to avoid dangling references forces us to keep alive at least
> what we need to, and sometimes a bit more.
>

"Need to" in the sense of strongly referenced, absolutely. Any
implementation that fails to do so seriously violates the spec and more.
There is no controversy on this point.

The concern is "need to" in the sense that a given program points at
something only weakly at t1, fetches is at t2 and finds it still there and
comes to count on that behavior. A different correct implementation might
cause this same program to find that the object has been collected before
t2, causing this buggy program to break.


>
> I guess a program could rely on the weak references actually being strong
> in some implementation.  I haven’t heard of Java programs ever doing that.
> It’s unlikely to happen because the major implementations will try to clear
> weak refs as aggressively as they can to compete on benchmarks.
>
> Perhaps part of the problem here is that we’re assuming that GC is already
> not observable.  It’s totally observable.  We have to fix bugs sometimes
> because the GC didn’t free something it should have, and the memory
> footprint of an app balloons so much that it crashes.  Also, people obsess
> over GC perf and GC pauses exactly because they observe them.  Considering
> all of the existing ways that GCs are observable, I don’t think that weak
> refs change the game.
>

I can only see this argument becoming solid if we were willing to consider
obligating the platform to do accurate gc, rather than conservative gc. 1)
no one is willing to advocate that, including me. 2) Even if we were, the
timing would still cause all the same issues.


> I think there are features of the web platform that are significantly more
> likely to create incompatibilities than this issue, and you seem to agree:
>
>
> The parallel scenario for data races is clear. And on some measures, the
> magnitude of the problem is orders of magnitude larger for SAB because of
> * the fine granularity of non-deterministic interleaving (especially if
> observable gc interleaving happens only at turn boundaries),
> * the greater difficultly of reasoning about memory models vs observable
> gc (again, especially if observable gc interleaving happens only at turn
> boundaries).

Re: Observable GC

[Filip Pizlo]

> On Oct 20, 2017, at 10:29 AM, Mark Miller  wrote:
> 
> There is a glaring inconsistency in the criteria we use to evaluate these 
> issues. While we are understandably reluctant to admit more non-determinism 
> into the platform via weakrefs, we have admitted an astonishingly greater 
> degree of non-determinism into the platform via "Shared Array Buffers" (SAB), 
> i.e., shared memory multithreading with data races.
> 
> The scenario we legitimately fear for weakrefs: A developer writes code that 
> is not correct according to the weakref specification but happens to work on 
> present implementations. Perhaps it relies on something being collected that 
> is not guaranteed to be collected.

Being collected when it shouldn’t have been?  Like a dangling reference.  The 
game theory of security exploits forces implementations to keep things alive 
longer, not shorter.

> Perhaps it relies on something not being collected that is not guaranteed not 
> to be collected. A later correct change to an implementation, or another 
> correct implementation, causes that code to break. The game theory punishes 
> the correct implementation rather than the incorrect code.

Java had weak refs and multiple different implementations.  My claim, as 
someone who implemented lots of weird GC algorithms in Java, is that I don’t 
know of a case where different weak ref semantics breaks something.  The only 
time that getting it wrong ever had an observably bad effect is when you break 
weak refs or finalizers so badly that they never get cleared or called, and 
then some resource has an unbounded leak.  This usually results in not being 
able to run any benchmarks that have weak references or finalizers, so you fix 
those bugs pretty quickly.

Here are the motivations:
- Competitive perf motivates GC authors to try to free things as soon as 
possible.  Smaller heaps mean more speed.  Some benchmarks won’t run to 
completion if you aren’t aggressive enough.
- The need to avoid dangling references forces us to keep alive at least what 
we need to, and sometimes a bit more.

I guess a program could rely on the weak references actually being strong in 
some implementation.  I haven’t heard of Java programs ever doing that.  It’s 
unlikely to happen because the major implementations will try to clear weak 
refs as aggressively as they can to compete on benchmarks.

Perhaps part of the problem here is that we’re assuming that GC is already not 
observable.  It’s totally observable.  We have to fix bugs sometimes because 
the GC didn’t free something it should have, and the memory footprint of an app 
balloons so much that it crashes.  Also, people obsess over GC perf and GC 
pauses exactly because they observe them.  Considering all of the existing ways 
that GCs are observable, I don’t think that weak refs change the game.

I think there are features of the web platform that are significantly more 
likely to create incompatibilities than this issue, and you seem to agree:

> 
> The parallel scenario for data races is clear. And on some measures, the 
> magnitude of the problem is orders of magnitude larger for SAB because of 
> * the fine granularity of non-deterministic interleaving (especially if 
> observable gc interleaving happens only at turn boundaries),
> * the greater difficultly of reasoning about memory models vs observable gc 
> (again, especially if observable gc interleaving happens only at turn 
> boundaries).
> 
> At least we all already understand that the side channel information-leakage 
> opened up by SAB is orders of magnitude larger than that opened up by 
> weakrefs, and so this is not generally raised as an additional argument 
> against weakrefs for a platform that has already admitted SAB.
> 
> I will start a separate thread on making the computation within an individual 
> turn more deterministic. SAB aside, the threats to intra-turn determinism can 
> and should be reduced. All the arguments against non-determinism in general 
> should be at least as strong against intra-turn non-determinism specifically.

Can you clarify what you think this means for weak refs?

-Filip


> 
> 
> 
> On Fri, Oct 20, 2017 at 9:54 AM, Dean Tribble  > wrote:
> I do think that we need weak references for all the reasons given in the 
> proposal. But indeed non-determinism is a concern. The reference Dominic 
> pointed at is one of two primary (areas of) considerations. The other is just 
> how many amazing things you can do if turns are deterministic (more reliable 
> testing, replay debugging, checkpoint/retry in the event of component 
> failure, simpler correctness analysis on code, etc.). 
> 
> Exposing non-determinism only at turn boundaries and controlling access to 
> the ability to observe GC both help some with the first motivation above (and 
> a lot with the second). However, not enough.  I'm hoping to make another run 
> at weakrefs in 

Re: Observable GC

[Mark Miller]

There is a glaring inconsistency in the criteria we use to evaluate these
issues. While we are understandably reluctant to admit more non-determinism
into the platform via weakrefs, we have admitted an astonishingly greater
degree of non-determinism into the platform via "Shared Array Buffers"
(SAB), i.e., shared memory multithreading with data races.

The scenario we legitimately fear for weakrefs: A developer writes code
that is not correct according to the weakref specification but happens to
work on present implementations. Perhaps it relies on something being
collected that is not guaranteed to be collected. Perhaps it relies on
something not being collected that is not guaranteed not to be collected. A
later correct change to an implementation, or another correct
implementation, causes that code to break. The game theory punishes the
correct implementation rather than the incorrect code.

The parallel scenario for data races is clear. And on some measures, the
magnitude of the problem is orders of magnitude larger for SAB because of
* the fine granularity of non-deterministic interleaving (especially if
observable gc interleaving happens only at turn boundaries),
* the greater difficultly of reasoning about memory models vs observable gc
(again, especially if observable gc interleaving happens only at turn
boundaries).

At least we all already understand that the side channel
information-leakage opened up by SAB is orders of magnitude larger than
that opened up by weakrefs, and so this is not generally raised as an
additional argument against weakrefs for a platform that has already
admitted SAB.

I will start a separate thread on making the computation within an
individual turn more deterministic. SAB aside, the threats to intra-turn
determinism can and should be reduced. All the arguments against
non-determinism in general should be at least as strong against intra-turn
non-determinism specifically.



On Fri, Oct 20, 2017 at 9:54 AM, Dean Tribble  wrote:

> I do think that we need weak references for all the reasons given in the
> proposal. But indeed non-determinism is a concern. The reference Dominic
> pointed at is one of two primary (areas of) considerations. The other is
> just how many amazing things you can do if turns are deterministic (more
> reliable testing, replay debugging, checkpoint/retry in the event of
> component failure, simpler correctness analysis on code, etc.).
>
> Exposing non-determinism only at turn boundaries and controlling access to
> the ability to observe GC both help some with the first motivation above
> (and a lot with the second). However, not enough.  I'm hoping to make
> another run at weakrefs in November with some changes to help concern #1
> further.
>
> On Fri, Oct 20, 2017 at 7:54 AM, Filip Pizlo  wrote:
>
>>
>>
>> > On Oct 20, 2017, at 7:45 AM, Mike Samuel  wrote:
>> >
>> >> On Fri, Oct 20, 2017 at 10:33 AM, Filip Pizlo 
>> wrote:
>> >> For what it’s worth, I have never agreed with this policy. This policy
>> seems
>> >> to be based on feelings not facts.
>> >>
>> >> I remember implementing real time GCs for Java, which changed GC
>> timing and
>> >> behavior a lot, and having zero problem getting that aspect of the GC
>> to
>> >> work well with existing code. It seems like we are using non-problems
>> to
>> >> make excuses to avoid supporting something useful.
>> >>
>> >> In fact, WeakMap is more restrictive constraint on GC algo than weak
>> refs or
>> >> finalization or whatever, since it means that a Siebert-style
>> fine-grained
>> >> incremental GC with O(1) increments is off the table.
>> >
>> > I'm not familiar with Siebert GCs so I apologize if this is beside
>> > your point.   My recollection of those discussions was that we
>> > rejected weak refs in favor of ephemerons because weak references are
>> > still prone to uncollectible cycles that involve a weakly referenced
>> > object being used as both a key and a value.
>>
>> It’s better to have both. Some use cases are not covered by WeakMap, as
>> evidenced by the fact that people still ask for weak refs or a gc trigger
>> or notification.
>>
>> -Filip
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
  Cheers,
  --MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Observable GC

[Filip Pizlo]

> On Oct 20, 2017, at 7:45 AM, Mike Samuel  wrote:
> 
>> On Fri, Oct 20, 2017 at 10:33 AM, Filip Pizlo  wrote:
>> For what it’s worth, I have never agreed with this policy. This policy seems
>> to be based on feelings not facts.
>> 
>> I remember implementing real time GCs for Java, which changed GC timing and
>> behavior a lot, and having zero problem getting that aspect of the GC to
>> work well with existing code. It seems like we are using non-problems to
>> make excuses to avoid supporting something useful.
>> 
>> In fact, WeakMap is more restrictive constraint on GC algo than weak refs or
>> finalization or whatever, since it means that a Siebert-style fine-grained
>> incremental GC with O(1) increments is off the table.
> 
> I'm not familiar with Siebert GCs so I apologize if this is beside
> your point.   My recollection of those discussions was that we
> rejected weak refs in favor of ephemerons because weak references are
> still prone to uncollectible cycles that involve a weakly referenced
> object being used as both a key and a value.

It’s better to have both. Some use cases are not covered by WeakMap, as 
evidenced by the fact that people still ask for weak refs or a gc trigger or 
notification. 

-Filip

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Observable GC

[Mike Samuel]

On Fri, Oct 20, 2017 at 10:33 AM, Filip Pizlo  wrote:
> For what it’s worth, I have never agreed with this policy. This policy seems
> to be based on feelings not facts.
>
> I remember implementing real time GCs for Java, which changed GC timing and
> behavior a lot, and having zero problem getting that aspect of the GC to
> work well with existing code. It seems like we are using non-problems to
> make excuses to avoid supporting something useful.
>
> In fact, WeakMap is more restrictive constraint on GC algo than weak refs or
> finalization or whatever, since it means that a Siebert-style fine-grained
> incremental GC with O(1) increments is off the table.

I'm not familiar with Siebert GCs so I apologize if this is beside
your point.   My recollection of those discussions was that we
rejected weak refs in favor of ephemerons because weak references are
still prone to uncollectible cycles that involve a weakly referenced
object being used as both a key and a value.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Observable GC

[Filip Pizlo]

For what it’s worth, I have never agreed with this policy. This policy seems to 
be based on feelings not facts. 

I remember implementing real time GCs for Java, which changed GC timing and 
behavior a lot, and having zero problem getting that aspect of the GC to work 
well with existing code. It seems like we are using non-problems to make 
excuses to avoid supporting something useful.

In fact, WeakMap is more restrictive constraint on GC algo than weak refs or 
finalization or whatever, since it means that a Siebert-style fine-grained 
incremental GC with O(1) increments is off the table.

-Filip

> On Oct 20, 2017, at 5:59 AM, Domenic Denicola  wrote:
> 
> https://w3ctag.github.io/design-principles/#js-gc
>  
> From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Michal 
> Wadas
> Sent: Friday, October 20, 2017 08:07
> To: es-discuss@mozilla.org
> Subject: Observable GC
>  
> Hi.
> 
> Is there any comprehensive answer about why ability to observe garbage 
> collection is considered undesirable in JavaScript?
> 
> Michał Wadas
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Observable GC

[Domenic Denicola]

https://w3ctag.github.io/design-principles/#js-gc

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Michal 
Wadas
Sent: Friday, October 20, 2017 08:07
To: es-discuss@mozilla.org
Subject: Observable GC

Hi.
Is there any comprehensive answer about why ability to observe garbage 
collection is considered undesirable in JavaScript?
Michał Wadas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Observable GC

[Mike Samuel]

IIRC, Most sources of non-determinism are obvious:
  * Builtins like Date and Random
  * Host environment artifacts like network message receipt order
and a piece of code that doesn't rely on one of those is deterministic.
There are a few sources of non-determinism that are hard to statically rule out:
  * Catchable exceptions due to lack of memory or stack overflow
but you can still reason about fail-stop deterministic code.

If GC is observable then the set of statements that are obviously
deterministic by either metric is much smaller.

Sources of non-determinism are also sources of hard-to-diagnose heisenbugs.
I don't know too much about how carving out a deterministic subset of
the language might be handy otherwise, but non-determinism and
side-channels often go hand in hand.



On Fri, Oct 20, 2017 at 8:07 AM, Michał Wadas  wrote:
> Hi.
>
> Is there any comprehensive answer about why ability to observe garbage
> collection is considered undesirable in JavaScript?
>
> Michał Wadas
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Observable GC

[Michał Wadas]

Hi.

Is there any comprehensive answer about why ability to observe garbage
collection is considered undesirable in JavaScript?

Michał Wadas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: styleguide sanity-check for tc39 language-proposals to address javascript-fatigue

[Michał Wadas]

Though, PEP-8 was created in 2001 and in significant part codified already
used conventions. And JavaScript does not have such widely followed
conventions - except camelCase for functions and PascalCase for classes.

On Fri, Oct 20, 2017 at 10:19 AM, Alexander Jones  wrote:

> I used the term 'language contributors' rather than TC39 as an
> intentionally vague way of describing people like us.
>
> The ISO C++ Committee also lacks a consensus on everything, but that
> doesn't mean those people and the people around them can't debate and
> establish a consensus on *something*. Hence, C++ Core Guidelines.
>
> I think the reality is that people are averse to this because they don't
> want their pet practices at work being discouraged by anything resembling
> official guidance — having to justify a decision to use `var` instead of
> `const` by default is *effort*, right? But they're perhaps not always
> considering the benefits that an improvement in (not necessarily total)
> uniformity can bring.
>
> I claim that the majority in the Python community would say that PEP-8 has
> been a net benefit. (Yes I break its rules from time to time. That's what
> rules are for. ;) )
>
> On 20 October 2017 at 00:54, Isiah Meadows  wrote:
>
>> In general, it's not the TC39 who should be dictating how code is
>> written - in particular, even they have their stylistic disagreements
>> (like with ASI and `let` vs `const`), and active TC39 representative
>> maintain both JSHint (opinionated) and ESLint (unopinionated).
>> Additionally, JSLint (the predecessor to JSHint) was created by a
>> formerly active TC39 representative. If you want to see more of these
>> broad stylistic disagreements, check out [their meeting notes][1]. A
>> few things that come to mind are decorators, cancellation, recent
>> class additions, and [BigInt][2].
>>
>> Instead, if you have your own strong opinions on everything, try
>> introducing [ESLint][3] to your projects. They have numerous presets
>> and rules built-in, and you can create your own custom presets, rules,
>> and plugins. If you want to ban `null`, write a custom rule for it. If
>> you want to ban anything not ES5, write a rule that catches every
>> expression that isn't ES5. If you want to define local rules, use
>> [eslint-plugin-local][4]. In my case, I decided I didn't want to use
>> default exports, so I wrote a local rule banning all default exports.
>> Not that I have a problem with those who use it - I don't. I just feel
>> it's easier for me to wrap my head around named exports without
>> introducing the cognitive overhead of default exports.
>>
>> [1]: https://esdiscuss.org/notes
>> [2]: https://esdiscuss.org/notes/2017-01-25#15iv-progress-report-
>> and-request-for-comments-on-64-bit-int-support
>> [3]: https://eslint.org/
>> [4]: https://github.com/taskworld/eslint-plugin-local
>> -
>>
>> Isiah Meadows
>> m...@isiahmeadows.com
>>
>> Looking for web consulting? Or a new website?
>> Send me an email and we can get started.
>> www.isiahmeadows.com
>>
>>
>> On Wed, Oct 18, 2017 at 6:37 AM, Naveen Chawla 
>> wrote:
>> > I disagree that the language contributors should be involved in best
>> > practice guidance. Patterns evolve over usage and experience with the
>> > constructs. I bet the implementors of `&&` and `||` didn't necessarily
>> > expect them to be used so effectively for non-boolean logic e.g. `car &&
>> > car.drive()` instead of `if(car!==undefined) car.drive()` or
>> whatever... Or
>> > maybe they did. But the point is language usage is often a matter of
>> opinion
>> > and preference, and not something that should be set as a tide against a
>> > possibly justifiable opposition. As a response to the original
>> question, I
>> > gave my opinion and reason in brackets. If the reader prefers a
>> different
>> > way for their own reasons, fine - I would just expect them to give
>> their own
>> > reasons for superseding my reasons...
>> >
>> > On Wed, 18 Oct 2017 at 14:34 Alexander Jones  wrote:
>> >>
>> >> The beauty of (coding) standards is that there are so many to choose
>> from.
>> >> :)
>> >>
>> >> IMO it’s a false dichotomy though. A respected and credible group of
>> >> language contributors should pool some energy together and ratify some
>> >> opinionated best practices, a la the C++ Core Guidelines and PEP-8.
>> No, it’s
>> >> not *necessary*—neither is the exponent operator—but it does have clear
>> >> benefits.
>> >>
>> >> I believe most in the community would rather not have to sell things
>> like
>> >> “const by default” to their team members, when it could be “official”
>> >> guidance instead. It’s energy we’d rather be spending on other things!
>> >>
>> >> Alex
>> >>
>> >> On Wed, 18 Oct 2017 at 06:59, Jordan Harband  wrote:
>> >>>
>> >>> These questions have consumed programmers in most languages since
>> >>> forever. It's not TC39's place to tell people how 

Re: styleguide sanity-check for tc39 language-proposals to address javascript-fatigue

[Alexander Jones]

I used the term 'language contributors' rather than TC39 as an
intentionally vague way of describing people like us.

The ISO C++ Committee also lacks a consensus on everything, but that
doesn't mean those people and the people around them can't debate and
establish a consensus on *something*. Hence, C++ Core Guidelines.

I think the reality is that people are averse to this because they don't
want their pet practices at work being discouraged by anything resembling
official guidance — having to justify a decision to use `var` instead of
`const` by default is *effort*, right? But they're perhaps not always
considering the benefits that an improvement in (not necessarily total)
uniformity can bring.

I claim that the majority in the Python community would say that PEP-8 has
been a net benefit. (Yes I break its rules from time to time. That's what
rules are for. ;) )

On 20 October 2017 at 00:54, Isiah Meadows  wrote:

> In general, it's not the TC39 who should be dictating how code is
> written - in particular, even they have their stylistic disagreements
> (like with ASI and `let` vs `const`), and active TC39 representative
> maintain both JSHint (opinionated) and ESLint (unopinionated).
> Additionally, JSLint (the predecessor to JSHint) was created by a
> formerly active TC39 representative. If you want to see more of these
> broad stylistic disagreements, check out [their meeting notes][1]. A
> few things that come to mind are decorators, cancellation, recent
> class additions, and [BigInt][2].
>
> Instead, if you have your own strong opinions on everything, try
> introducing [ESLint][3] to your projects. They have numerous presets
> and rules built-in, and you can create your own custom presets, rules,
> and plugins. If you want to ban `null`, write a custom rule for it. If
> you want to ban anything not ES5, write a rule that catches every
> expression that isn't ES5. If you want to define local rules, use
> [eslint-plugin-local][4]. In my case, I decided I didn't want to use
> default exports, so I wrote a local rule banning all default exports.
> Not that I have a problem with those who use it - I don't. I just feel
> it's easier for me to wrap my head around named exports without
> introducing the cognitive overhead of default exports.
>
> [1]: https://esdiscuss.org/notes
> [2]: https://esdiscuss.org/notes/2017-01-25#15iv-progress-
> report-and-request-for-comments-on-64-bit-int-support
> [3]: https://eslint.org/
> [4]: https://github.com/taskworld/eslint-plugin-local
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
>
> Looking for web consulting? Or a new website?
> Send me an email and we can get started.
> www.isiahmeadows.com
>
>
> On Wed, Oct 18, 2017 at 6:37 AM, Naveen Chawla 
> wrote:
> > I disagree that the language contributors should be involved in best
> > practice guidance. Patterns evolve over usage and experience with the
> > constructs. I bet the implementors of `&&` and `||` didn't necessarily
> > expect them to be used so effectively for non-boolean logic e.g. `car &&
> > car.drive()` instead of `if(car!==undefined) car.drive()` or whatever...
> Or
> > maybe they did. But the point is language usage is often a matter of
> opinion
> > and preference, and not something that should be set as a tide against a
> > possibly justifiable opposition. As a response to the original question,
> I
> > gave my opinion and reason in brackets. If the reader prefers a different
> > way for their own reasons, fine - I would just expect them to give their
> own
> > reasons for superseding my reasons...
> >
> > On Wed, 18 Oct 2017 at 14:34 Alexander Jones  wrote:
> >>
> >> The beauty of (coding) standards is that there are so many to choose
> from.
> >> :)
> >>
> >> IMO it’s a false dichotomy though. A respected and credible group of
> >> language contributors should pool some energy together and ratify some
> >> opinionated best practices, a la the C++ Core Guidelines and PEP-8. No,
> it’s
> >> not *necessary*—neither is the exponent operator—but it does have clear
> >> benefits.
> >>
> >> I believe most in the community would rather not have to sell things
> like
> >> “const by default” to their team members, when it could be “official”
> >> guidance instead. It’s energy we’d rather be spending on other things!
> >>
> >> Alex
> >>
> >> On Wed, 18 Oct 2017 at 06:59, Jordan Harband  wrote:
> >>>
> >>> These questions have consumed programmers in most languages since
> >>> forever. It's not TC39's place to tell people how to write code - but
> >>> there's plenty of style guides that have answers to these questions.
> >>>
> >>> On Tue, Oct 17, 2017 at 10:44 PM, kai zhu  wrote:
> 
>  there are several factors for the current javascript-fatigue.  one
>  factor which tc39 could help mitigate is to provide a narrative on
> how to
>  consistently apply proposed language-features (over
>