Guidelines and General Direction for Standard Library Proposals

Sun Aug 6 14:57:58 UTC 2017

I agree - neural networks should not belong to standard library. And that's
why I said that PHP is overbloated.

But you claimed that JS standard library is similar in size to PHP - but it
isn't, it's much, much smaller.

Deque isn't exotic data structure - but something needed. Basic trees are
not exotic. Judy Arrays can be considered exotic, though.

Compare Python's library to JS. https://docs.python.org/3/library/index.html
Big part of it isn't relevant to JavaScript (interactions with external
world are left to vendor), but even then Python have everything that have
JS and much more.

On 6 Aug 2017 2:45 pm, "kai zhu" <kaizhu256 at gmail.com> wrote:

> no, its far more practical and cost-efficient to leverage existing
> algo/neural libs through wasm than to try and reinvent them in javascript
> (and constantly change the language spec), if there is a need for them.
>  let javascript do what it does best - as a high-level glue-language for
> web-development.  and let the people who hate javascript happily write
> their algo libraries in c#/c++/java/etc and ship it as wasm. win-win.
>
> On Aug 6, 2017, at 8:30 PM, Eli Perelman <eli at eliperelman.com> wrote:
>
> > its NOT a low-level language for creating esoteric data-structures and
> algorithms in academia that have little relevance to web-development.
>
> Let's not get into the realm of opinion stated as fact. It also doesn't
> make sense to say that some things are useful in Node.js but then deny
> other things because they aren't useful for web development.
>
> There's no reason JS can't be more low level, and I find that enabling
> some of these low level standard libs would be beneficial, even for web
> development. The reality is that JS is a language that exists in many
> environments including the web, servers, and hardware/bare metal, where
> package dependency considerations are real. Keep that in mind. :)
>
> Thanks,
>
> Eli Perelman
>
> On Sun, Aug 6, 2017, 6:44 AM kai zhu <kaizhu256 at gmail.com> wrote:
>
>> inline
>>
>> WeakReferences,
>>
>> -1 footgun most web-devs have no idea how to use correctly (including me)
>>
>> OGG manipulation,
>>
>> -0.5 slightly prefer it as an npm module
>>
>> MPEG manipulation,
>>
>> -0.5 slightly prefer it as an npm module
>>
>> builtin support for Kerberos,
>>
>> impartial
>>
>> Bzip2 bindings,
>>
>> -1 use nodejs child_process system calls to bzip2.  i don’t see any
>> common use-case for bzip2 other than file-to-file operations which can be
>> accomplished with shell-scripting.
>>
>> Zlib bindings,
>>
>> already a nodejs builtin
>>
>> configurable random number generation,
>>
>> -1 Math.random is good-enough for most use-cases.  for the
>> normal-distribution use-case, its easy enough to write your own transform
>> with sine/cosine.
>>
>> OpenSSL bindings,
>>
>> already a nodejs builtin
>>
>> simple hashing,
>>
>> +1 would be nice to have
>>
>> drivers for databases,
>>
>> +1 a STABLE nodejs sqlite3 builtin is sorely needed for embedded systems
>> (instead of the flaky npm module), but need to nag nodejs folks, not tc39
>>
>> ImageMagick bindings,
>>
>> -1 use nodejs child_process system calls to imagemagick.  i'm skeptical
>> builtin bindings would be significantly more efficient enough to be worth
>> the effort.
>>
>> arbitrary precision math,
>>
>> -0.5 generally against due to it confusing people with 2 different
>> numeric types, though i slightly sympathize with accounting/finance
>> use-cases for decimal arithmetic.
>>
>> statistics support,
>>
>> +1 would be useful
>>
>> GPG support,
>>
>> impartial
>>
>> PostScript support,
>>
>> -1 use nodejs child_process system calls, as bindings would not be
>> significantly more efficient.
>>
>> Judy Arrays,
>>
>> -1 too esoteric and confusing to understand what the use-cases are for
>> most web-devs
>>
>> neural networks,
>>
>> -1 slightly too big a scope, and more the domain of wasm
>>
>> Lua integration,
>>
>> Impartial
>>
>> FTP support,
>>
>> -0.5 i don’t see much use-case for an ftp-client but i may be wrong
>>
>> XML support,
>>
>> impartial
>>
>> 9 data structures,
>>
>> -1 javascript is a high-level language with a builtin feature-set
>> targeted for expressing high-level concepts like ajax, file-uploads,
>> event-handling, dom-manipulations, programmable forward/reverse proxies,
>> etc.  its NOT a low-level language for creating esoteric data-structures
>> and algorithms in academia that have little relevance to web-development.
>>
>> recursive iterators
>>
>> javascript already has recursive closures that i frequently use like
>> recursive iterators
>>
>>
>> On Aug 6, 2017, at 5:40 PM, Michał Wadas <michalwadas at gmail.com> wrote:
>>
>> I disagree.
>> PHP have WeakReferences, OGG manipulation, MPEG manipulation, builtin
>> support for Kerberos, Bzip2 bindings, Zlib bindings, configurable random
>> number generation, OpenSSL bindings, simple hashing, drivers for databases,
>> ImageMagick bindings, arbitrary precision math, statistics support, GPG
>> support, PostScript support, Judy Arrays, neural networks, Lua integration,
>> FTP support, XML support, 9 data structures, recursive iterators with well
>> defined interfaces etc.
>>
>> All of them are missing in JavaScript. PHP have extremely bloated
>> standard library - and JS have very minimal one.
>>
>> On Sun, Aug 6, 2017 at 4:32 AM, kai zhu <kaizhu256 at gmail.com> wrote:
>>
>>> my thoughts are the opposite. javascript (similar to perl and php)
>>> already has a huge number of specialized builtin functions and methods
>>> accumulated over its 20+ year evolution that pretty much solves every
>>> practical problem encountered in frontend programming (and effectively
>>> backend as well). the problem is a failure to educate new programmers on
>>> how to use existing builtins to elegantly solve everyday problems, instead
>>> of having them ignorantly reinvent things on their own.
>>>
>>> the mindset to writing javascript programs is more akin to writing perl
>>> programs, e.g. "how do i leverage builtins to implement the requested
>>> one-off UX feature using elegant perl-like one-liners", instead of "how do
>>> i create extra abstractions, classes, and modules to implement this one-off
>>> UX feature".
>>> My thoughts: big source of JavaScript criticism is its small standard
>>> library and community attempts to solve that issue - hundreds of small
>>> modules. Significant part of lodash should be present in standard library.
>>> My lodash selection - chunk, dropWhile, first, last, flatten, fromPairs,
>>> pull, without, takeWhile, zip, flatMap, keyBy, property, groupBy,
>>> partition, sample, shuffle, sortBy, ary, memoize, once, operators as
>>> functions, clamp, inRange, get, mapKeys, mapValues, pickBy, many strings
>>> operations, attempt, constant, flow, noop, range.
>>>
>>>
>>> On Sat, Aug 5, 2017 at 1:22 PM, T.J. Crowder <
>>> tj.crowder at farsightsoftware.com> wrote:
>>>
>>>> I'd find it helpful to have:
>>>>
>>>> 1. A general steer from TC39 as to whether the committee are committed
>>>> to a robust, feature-rich standard library, or a minimal one (with the
>>>> expectation of a rich ecosystem of libraries, presumably).
>>>>
>>>> 2. Guidelines of what to consider when proposing standard library
>>>> features.
>>>>
>>>> The latter can come from the community; the former needs to come from
>>>> TC39.
>>>>
>>>> We see a fair number of simple lib function proposals on the list, it
>>>> would be useful to have some guidelines for what's worth properly
>>>> proposing and what's likely to be a non-starter.
>>>>
>>>> Naveen Chawla's [recent suggestion][1] is a good case in point: A
>>>> standard lib function for taking an array (ideally, an iterable) and
>>>> creating an object with properties referencing the elements by one of
>>>> their property's values. (One could easily argue for a Set version as
>>>> well.) Ignoring the details of his suggestion, this is a simple
>>>> operation that I've needed in every codebase I've ever worked on. I
>>>> haven't proposed it (having considered doing so repeatedly) because my
>>>> perception had been that TC39 wants to keep the standard lib small.
>>>> But with the additions in 2015, 2016, and 2017, is that simply not the
>>>> case (anymore)?
>>>>
>>>> Apologies if either (1) or (2) already exist and I've overlooked them.
>>>>
>>>> -- T.J. Crowder
>>>>
>>>> [1]: https://esdiscuss.org/topic/array-prototype-
>>>> toobjectbyproperty-element-element-property
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss at mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170806/7f5d283e/attachment.html>