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 <e...@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 <kaizhu...@gmail.com 
> <mailto:kaizhu...@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 <michalwa...@gmail.com 
>> <mailto:michalwa...@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 <kaizhu...@gmail.com 
>> <mailto:kaizhu...@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.crow...@farsightsoftware.com <mailto:tj.crow...@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@mozilla.org <mailto:es-discuss@mozilla.org>
>> https://mail.mozilla.org/listinfo/es-discuss 
>> <https://mail.mozilla.org/listinfo/es-discuss>
>> 
>> 
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>
>> https://mail.mozilla.org/listinfo/es-discuss 
>> <https://mail.mozilla.org/listinfo/es-discuss>
>> 
>> 
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss 
> <https://mail.mozilla.org/listinfo/es-discuss>

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

Reply via email to