benjamin at cs.stanford.edu
Mon Oct 2 17:38:03 UTC 2017
Taking a step back from the details of this proposal, I have some thoughts
about why it seems to be struggling to find support.
In no particular order, I would say this proposal
- relies on microbenchmarks, which can be misleading
- disregards Amdahl's Law <https://en.wikipedia.org/wiki/Amdahl%27s_law>,
by pretending that real-world JS CPU usage is commonly/ever dominated by
- replaces two O(n) loops with another O(n) loop that does slightly more
work on each iteration, resulting in no complexity improvement, and a
fairly modest (< 2x) constant factor improvement
- doesn't seem to provide usability/learnability improvements for any
particular group of JS developers (for example, novice programmers)
- doesn't seem to prevent any common bugs in JS code
As a member of TC39, I regret that we have not provided a clearer set of
criteria for what it takes to get a new function into the standard library.
While I can't speak for the committee as a whole, my suspicion is that this
proposal is unlikely to meet that standard. It's a fine idea, but so are
many other functions that you can implement in a normal (non-standard)
I would also challenge the committee to think about (or link to!) any
concrete written criteria that someone with an idea for a proposal could
use to assess its chances of acceptance. Imagine how much time we could
On Mon, Oct 2, 2017 at 12:12 PM Xavier Stouder <xavier at stouder.io> wrote:
> JDecker: Just added your solution on the benchmark, it beats every
> others solution and it's a elegant solution.
> Kai Zhu: We can't see the screenshot. But please take in consideration
> that it's been a long time that ECMAScript isn't only used in webapp,
> and that some of applications using it can eat more than a million
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss