On Tue, Nov 28, 2017 at 6:19 AM, kai zhu <[email protected]> wrote:
> > On Tue, 28 Nov 2017 at 6:51 pm, T.J. Crowder < > [email protected]> wrote: > > You mean, it's a tool to write computer instructions for taking input, > manipulating it, and generating output? Breaking news: That's what all > programming languages are. > > @T.J. the thing about javascript as a "tool mainly for baton-passing > JSON-data around", > is that unlike other programming languages that take generic io data, > javascript has grown to be a generally useful language; and indeed because it had the ability to read generic IO data; maybe that's somewhat incorrect... systems supporting javascript have been created that allow generic IO. NodeOS https://node-os.com/ some really powerful fontend chosts - Electron and NWJS for instances ( above and beyond what a browser can do itself, or working standalone without requiring passing batons to anyone) 3D and Vr programming https://webvr.info/ https://threejs.org/ I used it to create 100's of millions of bingo cards (would have been able to do that faster if I had threads but broke it up into several processes in parallel and managed it quite quickly) Those got output as a binary format (also SQL and CSV flavors) It even works well to add logic to GUI elements created outside of a browser https://www.npmjs.com/package/sack.vfs#frame-methods I do think you're looking at the world somewhat myopically or with a bit of tunnel vision. While true, classes don't help in basically any of those cases... and they really tke javascript as just the pure functional language it started as ( just like it's C roots, which I found rather amused that Functional Programming is this 'grand new thing that javascript does' I would have used classes more, but since they encapsulate no data, I found them more of a hinderance to develop since I had to do all the work in a constructor/factory anyway the extra cryptic layer I find unnessecary. If it had supported data fields, I'd think there would be additional performance benefits to having a full template, without having to adjust underlaying tracking to add fields all the time. >From long time in C, my development practice is always to create the data structures I'm using and then create the functions to manipulate said structures; having functions first and nothing to operate on is kinda useless... Javascript does such a habit a little harder to follow, requiring a factory for the structure first like these ... https://github.com/mrdoob/three.js/tree/dev/src/math vectors, matrixes, etc.... > javascript oftentimes doesn't need a > class-abstraction layer to parse the input, or serialilze to output, > because they are already in JSON. > > i already demonstrated the feasibility of a non-trivial webapp > that has no class-abstraction layer - > it relies on static-functions instead to directly manipulate > JSON/plain-text > to/from io (aside from builtin classes like XMLHttpRequest that i have > to use for ajax). > > showing you can efficiently manage javascript's JSON-focused io with > static-functions and no class-abstraction layer then raises the > question of the necessity of all the class-related tc39 proposals > being considered. > > demo urls: > 1. https://kaizhu256.github.io/node-swgg-google-maps/build.. > beta..travis-ci.org/app/#!swgg_id__2Fmaps_2Fapi_ > 2Fdirections_2Fjson_20GET_1 > > 2. https://kaizhu256.github.io/node-swgg-wechat-pay/build.. > beta..travis-ci.org/app/#!swgg_id__2Fpay_2Fmicropay_20POST_1 > > > > > On 11/28/17, Naveen Chawla <[email protected]> wrote: > > I oppose moderation. These views about ES, however misguided they might > > seem, allow us to reaffirm the reasons why decisions were made and guide > > those with similar views to the answers to their concerns. I don't see > any > > loss, only gain, in engaging these concerns. > > > > On Tue, 28 Nov 2017 at 13:46 James Kyle <[email protected]> wrote: > > > >> I don't understand what this thread is even trying to achieve. > >> > >> This mailing list should really just be shut down. The lack of > moderation > >> ruins it and it sucks having to subscribe to it for the occasional > >> important/interesting information/discussion. I'd rather have that > >> content > >> moved to one of the other channels of communication which have been more > >> successful. > >> > >> On Tue, 28 Nov 2017 at 6:51 pm, T.J. Crowder < > >> [email protected]> wrote: > >> > >>> On Tue, Nov 28, 2017 at 6:40 AM, kai zhu <[email protected]> wrote: > >>> > > >>> > if i were asked what the vision of javascript is my current > >>> > answer would be: > >>> > "javascript is a tool to take JSON-input, manipulate it, and > >>> > output it back out (via DOM, event-handling, network-socket, > >>> > file-io, or db-driver)." > >>> > >>> You mean, it's a tool to write computer instructions for taking input, > >>> manipulating it, and generating output? Breaking news: That's what all > >>> programming languages are. > >>> > >>> If you mean *specifically* JSON, and *specifically* a DOM, and > >>> *specifically* network I/O and DBs and...well, sorry; as you've been > >>> repeatedly told, *your* vision is at odds with that of the JavaScript > >>> community at large and, I believe, of the committee. JavaScript is > >>> bigger > >>> than that. Cope. Because I don't see that changing. Harping on about > >>> that > >>> conflict on this list is simply not useful. > >>> > >>> > es5 was the epitomy of achieving that vision in the simplest way > >>> possible. > >>> > >>> Great. Again: Keep using it. Nothing is stopping you or anyone else. > The > >>> committee have done a *huge* amount of work to maintain backward > >>> compatibility. (Speaking of which: In all the harping, I don't recall > >>> hearing a thing from you *appreciating* that hard work from the > >>> committee. > >>> Did I just miss it?) Yes, it's 99.99999999% instead of 100%, and code > >>> written assuming nothing would ever change (say, values from `typeof`) > >>> was > >>> ever-so-slightly impacted. Well, that's unfortunate, but it's very much > >>> an > >>> exception to the rule of compatibility, the decision was not made > >>> lightly > >>> or without research on impact, and it's not like it takes any > >>> significant > >>> time to fix the code in question. Rather less time than complaining > >>> about > >>> it on the list, in fact. > >>> > >>> You have a different view from most reasonably-informed people on this. > >>> You're entitled to it. As a reasonably-informed person, you're entitled > >>> to > >>> express it, and you have. It's time to move on. > >>> > >>> -- T.J. Crowder > >>> _______________________________________________ > >>> es-discuss mailing list > >>> [email protected] > >>> https://mail.mozilla.org/listinfo/es-discuss > >>> > >> _______________________________________________ > >> es-discuss mailing list > >> [email protected] > >> https://mail.mozilla.org/listinfo/es-discuss > >> > > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
