Guidelines and General Direction for Standard Library Proposals
Michael Kriegel
michael.kriegel at actifsource.com
Mon Aug 7 05:00:44 UTC 2017
Kai, you are not speaking for all Web-Developers here and Web-Developers
are not the only users of JavaScript, please keep that both in mind. If
you do not like the idea of e.g. weak references, do not use them. But
for some caching tasks it is just necessary and I would love to see them.
You wrote "...is a failure to educate new programmers on how to use
existing builtins to elegantly solve everyday problems..." - existing
builtins do not provide anything which can be used to get weak
references. And maybe you should educate yourself to find out, what a
feature like "weak references" can be used for. Else you are just not in
the position to say: "-1 footgun most web-devs have no idea how to use
correctly (including me)" - it is not a lack of the feature, but a lack
of yours. You shouldn't drive a train if you don't know how. But you
also should not say that trains are useless, just because you do not
know, how to operate them. I often saw, that you tend to argue that
features, which you do not like or not know how to use are not needed by
web developers, especially not in asia. Don't you think, that's a bit
arrogate?
On 06.08.2017 13:44, kai zhu 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
>> <mailto: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
>> <mailto: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
>> <mailto: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
>> <https://esdiscuss.org/topic/array-prototype-toobjectbyproperty-element-element-property>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>> https://mail.mozilla.org/listinfo/es-discuss
>> <https://mail.mozilla.org/listinfo/es-discuss>
>>
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>> https://mail.mozilla.org/listinfo/es-discuss
>> <https://mail.mozilla.org/listinfo/es-discuss>
>>
>>
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
--
Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 Baar • www.actifsource.com • +41 56 250 40 02
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170807/d8d00f3a/attachment-0001.html>
More information about the es-discuss
mailing list