Re: an operator for ignoring any exceptions

-1 in my real-world experience, JSON.parse and nodejs fs.readFileSync are the only 2 common use-cases that would benefit from this. its more practical to use helper-functions for those 2 use-cases rather than change the javascript language yet again (besides, returning an empty string is commonly

Re: import.meta and TC39 process as a whole

the rushed speccing of es6 modules is partly the reason people like me decided to join this discussion to voice opposition and provide inertia against such hugely disruptive changes in frontend programming. i see this as a feature that primarily benefits companies with large code-bases and

Re: import.meta and TC39 process as a whole

> I’m curious what the concerns were. You mentioned disliking the syntax, but > I’m guessing there’s more to it than that? the concern is that es modules are starting to look like a solution in search of a problem. its redundant and unnecessary on the server-side. and it continues to fail

Re: Proposing a conditional assignment (or equals) operator

this proposal is not as useful as you would think. when integrating with api's and modules not written by yourself, you will always be self-doubting whether the "other" guy who wrote their code used null/undefined/false/0/ values, causing you to avoid using this feature in general. the is

Re: Re: Defer expression

setTimeout is still the best solution in my mind. none of the promise or async code examples presented are as immediately obvious as setTimeout that the code is to self-run at a later time (and you don't need the 1ms argument). ```js // self-comment that this code will self-run // after the main

Re: Operator overloading proposal

-1 javascript operator-overloading is a solution in search of a problem. there is virtually no real-world use-case where this feature would would not cause surprises and code-bloat (from bloated and unmaintainable polymorphic classes dealing with all the edge cases). just imagine all the

Re: Operator overloading proposal

> No. It is a solution to a problem I have today: arithmetic on decimal values. would you enjoy debugging someone else’s production-code with overloaded decimal operators? or would you prefer them having the courtesy to use method-calls, thus saving the headache of having to inspect every

Re: Recent language addition suggestions

+1 > On Jul 17, 2017, at 7:24 PM, Isiah Meadows wrote: > > I've noticed lately that a lot of heavy syntax proposals [1] [2] [3] > have lately started appearing here that would only appeal to a small > niche audience (and not likely garner general use), and are more like

Re: JSON5

any significant degradation in json parsing-performance would impact the world wide web. can anyone knowledgeable on js engines comment on parsing performance? On Jul 11, 2017 15:39, "Dong Nguyen" wrote: > @Jordan: I think that's just work-around, not official feature. > >

Re: JSON5

.com> wrote: > > On Tue, Jul 11, 2017 at 3:48 AM, kai zhu <kaizhu...@gmail.com > <mailto:kaizhu...@gmail.com>> wrote: > any significant degradation in json parsing-performance would impact the > world wide web. can anyone knowledgeable on js engines comment on parsi

Re: Functional Operators

-1 i can see this becoming a debugging nightmare in math libraries where its confused with arithmetic expressions. yet-another-alien-syntax to remember when debugging other people's code. On Jul 11, 2017 03:35, "Vihan Bhargava" wrote: > As JS/ECMAScript gains more and more of

Re: Syntax for non-writability and non-configurability

-1 as far as i'm concerned, const is a wart with surprising behavior that should have never been introduced. best leave the wart as is rather than add more surprises. On Jul 8, 2017 3:09 PM, "Raul-Sebastian Mihăilă" wrote: > I'd like to propose the following syntax: > >

Re: Syntax for non-writability and non-configurability

legitimate Object.defineProperties use-case is low and obscure enough it can stay verbose. most of the time it causes more code-maintainability issues / tech-debt than it solves. On Jul 8, 2017 7:51 PM, "T.J. Crowder" wrote: > On Sat, Jul 8, 2017 at 8:09 AM,

Re: Operator overloading proposal

c²+d² > > Set symmetric difference (i.e. exclusive or): > > {1, 2, 3} ⊕ {1, 2, 4} = {3, 4} > > I'd strongly prefer an operator variant over any method version, because it > matches the math notation much better. You shouldn't actually need to learn > some na

Re: Recent language addition suggestions

> I would like to note that JavaScript is already starting to > feel a bit large, and we should definitely take greater care on > realizing the added complexity of new language features my personal opinion is that es6 was a net-negative creating chaos in the world of frontend-development (making

Re: Removal of language features

e many of these managers in asia who copy whatever they perceive is trending in silicon valley, with very little care about the technical-risks they bring to projects. > On Jul 22, 2017, at 5:14 AM, T.J. Crowder <tj.crow...@farsightsoftware.com> > wrote: > > On Fri

Re: Removal of language features

pragmas although not great and should be used sparingly, are still the most feasible way forward to limiting excessive features. that being said, es6 is such a different beast from es5, that i think a backwards-compatible “use es5” text pragma would be appreciated by the significant number of

Re: Removal of language features

> On Jul 23, 2017, at 10:58 AM, Vinnymac wrote: > > Above Steve mentions that many people are mixing language additions with > framework fatigue. I have to agree with him. In my case I am not overwhelmed > by any of the additions TC39 has chosen to make to ECMA. In fact it

Re: JavaScript Versioning

ubstantial > "+1" or > "-1" emails if they contain no meaningful contribution to the conversation? > > If you want to make a point, make your point. If not, don't. > > Much obliged! > > On Sunday, July 23, 2017 11:58:34 PM CEST kai zhu wrote:

Re: JavaScript Versioning

> On Jul 23, 2017, at 4:47 PM, Dante Federici > wrote: > > The bottom line here is that browsers aren't a place for a type safe and > correct language (well, thy could have been but hey, such is history). > They're a medium to consume information over the

Re: Removal of language features

On Jul 27, 2017, at 5:43 PM, Andreas Rossberg wrote: > > That is not always true. For example, ES6 has caused some notable performance > regressions for ES5 code initially, due to extensions to the object model > that made it even more dynamic. The new @@-hooks were

Re: Removal of language features

+1 On Jul 20, 2017 6:36 AM, "David White" wrote: > Hi, > > I’m just curious as there are a lot of proposals for the addition of > features to the ES specification, is there any scope for requests to remove > language features? Going via the same means of writing a

Re: Removal of language features

> On Jul 22, 2017, at 11:37 PM, Maggie Pint wrote: > > Having been a delegate to tc39 from the JS foundation for only about six > months, I can't claim authority to speak to all of the history here. That > said, I can very assuredly tell you there is a significant amount

Re: Pattern matching?

-1. will pattern matching code written by the vast number of beginner javascript programmers be readable/maintainable? i personally think not. yet another duplicative feature (that can probably be done more maintainably by switch statements or the all-powerful String.prototype.replace) to further

Re: Proxy performance: JIT-compilation?

of course Proxy is going to cause deoptimization problems when you start breaking assumptions about Object builtins (which obviously have more aggressive and specialized optimizations than generic methods). in v8, i understand the common-case optimization for builtin getters to be a direct

Re: Guidelines and General Direction for Standard Library Proposals

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).

Re: Guidelines and General Direction for Standard Library Proposals

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

Re: Stream + async await

so that everyday programmers can relate, can someone give a code-snippet of the proposal equivalent to the common-use nodejs example below? ```javascript function consumeReadableStream(stream, consumeChunk, callback) { /* * stream - readable stream * consumeChunk - has signature - function

Re: Stream + async await

the timeout handler will not work as advertised, e.g. what if io / db issues causes a network stream to intermittently respond in intervals far greater than 3ms or not at all? > On Jul 31, 2017, at 7:26 AM, James Browning wrote: > > It'll look something like

Re: Guidelines and General Direction for Standard Library Proposals

t's a bit arrogate? > yes it is arrogant of me. partly its because i care alot about javascript and am upset at how fast and loose people play with its language spec. you have to expect eventual pushback against things moving so fast (if not me, then from someone else eventually).

nits on BigInt Proposal

looking at the use-cases for this feature @ https://github.com/tc39/proposal-bigint#use-cases , i'm not convinced it improves everyday programming, or outweigh the benefit and simplicity having a single number type. my nits are: - will this

Re: Guidelines and General Direction for Standard Library Proposals

ython.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" <kaizhu...@gmail.com &

Re: Guidelines and General Direction for Standard Library Proposals

nd 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 > >>

Re: nits on BigInt Proposal

no, just use one BigInt padded with a bunch of zeroes (e.g. instead of $12.34, use 123400, and round to nearest integer for division). this is what i meant by “fixed point” decimal. for current javascript double-precision numbers, you can do integer arithmetic up to around

Re: Picking (deconstructing) properties into object literals

-1 and agree with isiah furthermore, i see javascript deconstruction as a never-ending can-of-worms that too-often devolves into ruby-esque confusion / arguments over the “best” way to do assignments. NO AMOUNT of language-spec changes will resolve all these arguments, so forget about it.

Re: Re: Defer expression

i can give you a specific solution to one of my async init problems (done entirely in vanilla es5 code). in this use-case, i want to run integrated tests, but have to wait for the server to listen on a port, and the db to be seeded first. to keep complexity at a manageable level, i find its

are there metrics on how es6 and future proposals affect javascript load-time for webpages?

and should future proposals take load-time performance into account? hi, i’m a new subscriber, and apologies if this seems like a newbie question. a bit of trivia - i remember long ago (maybe 2010?) a website called “great computer language shootout” or something had d8 consistently having the

Re: Allowing object field name shorthand

-1 this is a terrible idea in terms of debugging and code-maintennance. when debugging someone else's unfamiliar code, i now have to add an extra-check for quotes around the key. On Jun 23, 2017 1:36 AM, "T.J. Crowder" wrote: > If you know it's already valid

Re: are there metrics on how es6 and future proposals affect javascript load-time for webpages?

or > browsers in the first place. > > Aside from that, a great deal of "load time" (?) will likely consist of the > time needed to parse the source code. Anything else is mostly implementation- > specific and thus varies from engine to engine. > > Could you state your que

Re: Lazy evaluation

able over time. > > no, thanks. > > We were discussing patterns here, nothing to "please don't" and IMO, dogma > oriented rules are over-engineered anti-pattern too. > > Let's not make this ML an awkward place for who wants to just learn or > explore JS language

Re: Math.minmax

r <xav...@stouder.io > <mailto:xav...@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

Re: September meeting notes?

just noticed the notes are up now - https://github.com/tc39/tc39-notes/tree/master/es8/2017-09 -kai > On Oct 9, 2017, at 9:46 AM, Jordan Harband wrote: > > Typically, the notes are published after a week or two, so

Re: Mixing grammars

ure, and prefer something with minimal sugar, like es5 was. On Sep 6, 2017 11:20, "Michael Kriegel" <michael.krie...@actifsource.com> wrote: > > Quoting kai zhu: "more people like me might look at es9/10 code that may have this feature and think "this loo

Re: Mixing grammars

i tend to agree with peter that function-composition and pipe-operators are likely footguns that don't solve anything new, and that you should be careful what you wish for. like es6, its all fun when you're writing your own code, but not so much when you "inherit" someone else's orphaned

Re: A few module ideas

for the forseeable future, the only practical solution i see to these frontend performance issues is to avoid using es modules, and revert to the simple, old-fashioned method of assigning libraries to the window namespace. On 8/20/17, James Browning wrote: > These are

Re: Lazy evaluation

inline > On Sep 1, 2017, at 1:03 AM, Isiah Meadows wrote: > > It'd solve a problem similarly to Kotlin's `by lazy { ... }` delegate, > .NET's `System.Lazy`, Swift's `lazy var`, among many other > languages. It's very useful for lazy initialization [1], such as > lazily

Re: styleguide sanity-check for tc39 language-proposals to address javascript-fatigue

was a mistake and a step in the wrong-direction for javascript and frontend-development. -kai On Oct 18, 2017 3:02 PM, "T.J. Crowder" <tj.crow...@farsightsoftware.com> wrote: > > On Wed, Oct 18, 2017 at 6:44 AM, kai zhu > <kaizhu...@gmail.com> wrote: > > > &

Re: Make comma at the end of line optional

-1 for code-maintainability. i don’t see the benefits justifying the extra complexity and rules it adds to javascript style-guides and linters (and those who follow them). > On Sep 26, 2017, at 3:27 AM, Alexander Jones wrote: > > IIFEs start with a (. Putting line breaks before

styleguide sanity-check for tc39 language-proposals to address javascript-fatigue

there are several factors for the current javascript-fatigue. one factor which tc39 could help mitigate is to provide a narrative on how to consistently apply proposed language-features (over existing-practices and interfacing with legacy-code). i feel too many new and old

Re: How it feels to learn JavaScript in 2016

, and the current undefined behavior when its encountered in db drivers. On 11/26/17, Claude Pache <claude.pa...@gmail.com> wrote: > >> Le 25 nov. 2017 à 16:03, kai zhu <kaizhu...@gmail.com> a écrit : >> >> i disagree. you can write more maintainable and cleaner

Re: How it feels to learn JavaScript in 2016

> an >> object (since Symbols are primitives, they don't have persistent >> properties, for example). >> >> Code that's written as if things will never change is brittle; "paranoid" >> code isn't over-engineered, it's simply *engineered* to handle change &g

Re: A way to prevent properties to be added to an object if they are null or undefined.

@rodrigo, you can achieve most of what you want with a simple helper function. my suspicion is there are too many variations for this to be practical as a language proposal (e.g. you often want the empty string "" to be considered nullish as well for the special nodejs object process.env, which

Re: How it feels to learn JavaScript in 2016

i disagree. you can write more maintainable and cleaner code with the premise typeof's will never change again (and give a one-time pass for symbols), instead of over-engineered paranoid code that it *may* change again in the future. On 11/25/17, Oriol _ wrote: > It

Re: How it feels to learn JavaScript in 2016

On 10/28/17, Frederick Stark wrote: > I'd just like to thank TC39 for not breaking compatibility. All the niche > old libraries I use that were written in ES5 still work in my ES6+ projects > with no issues. introducing the new typeof Symbol() === 'symbol' does break

Re: FW: javascript vision thing

del, just with easier native subclassing. >> You could in theory replicate this in the rest of the language with a >> combination of `Object.defineProperty`, `Object.setPrototypeOf`, >> `new.target`, and existing ES5. >> - >> >> Isiah Meadows >> m...@isiahmeadows.com >

Re: Allow any quoted string to be multiline?

`` "auto remove trailing whitespace" autocmd BufRead,BufWrite * if ! | silent! %s/\s\+$//e | endif ``` not every problem in javascript demands a tc39 language-proposal-hammer. use some common-sense. > @Kai Zhu: As has been done in the past, I, too, would like to kindly ask if >

Re: Allow specify numbers with suffixes

> On Dec 13, 2017, at 2:15 AM, Sam Goto wrote: > > + rick that co-authored numeric separators too and may have thoughts on this. > my first impression is that this (if kept purely as something that gets > ignored by the VMs) shares a lot of the sentiments with numeric

Re: javascript vision thing

On Dec 19, 2017 01:36, "Naveen Chawla" wrote: > > Using static methods with plain objects can be cool if you don't want method overriding and/or inheritance. Otherwise using classes and methods makes that simpler to accomplish. @naveen, have you tried adding asynchronous

Re: javascript vision thing

i'm generally curious what the overall vision is for those who want continued aggressive evolution of the javascript-language. is it to transform javascript into a class-based language similar to c#? also, is another part of the vision to add features to javascript to solve special

Re: Re: import { foo, bar } as obj from 'module

we're talking about the same thing. class-based libraries like backbone.js for example cannot be tree-shaken. i've done manual tree-shaking for the entire frontend-stack for swagger-ui, by writing tests and doing deadcode-elimination from code-coverage. the takeaway from that was most of its

Re: import { foo, bar } as obj from 'module

> I don’t know how much of a factor this is in language design, but I think > this addition could have a nice side effect — it might help encourage > patterns that happen to play well with "tree shaking". tree-shaking is incompatible with class-inheritance and meta-programming in javascript.

Re: Shorthand for "function" keyword

the *this* in fat-arrows is irrelevant to frontend-developers who prefer to use static functions to manipulate json-data, rather than class instantiated-objects which are difficult to serialize / reconstruct when baton-passing between frontend <-> backend. On 11/14/17, Naveen Chawla

Re: Definition mixins

the problem is that you chose to write the chess program in javascript, instead of say, python or c#. why did you choose javascript? probably because you intend the chess program to be an online webapp. mixins, like classes, are inferior to plain json-objects for webapps. how do you intend to

javascript vision thing

any thoughts? i'll break the ice with a quora question i recently answered quora question: > Why is JavaScript so hated? answer posted: >the primary reason is because traditional oop skills gained from >c#/c++/java/python/etc translate poorly to javascript. > >in javascript, class-instantiated

Re: Web Docs

fyi, mozilla recently created a webpage to publicize its position on open Web and Web-related specifications submitted to standards bodies like the IETF, W3C, and Ecma TC39 @ https://mozilla.github.io/standards-positions/ the process to ask them for a position is to file a github issue @

Re: Question of the Day: What about all this asynchrony?

criticizing tc39 for the current problems in frontend-development is fair-game. many of theses issues wouldn't exist if tc39 had responsibly gatekeeped es6 with a more modest feature-set of languages-changes, instead of creating an entirely new language. On 11/9/17, Michael Lewis

Re: Identifying pure (or "pure within a scope") JavaScript functions?

the best way to use that library, I think it's worth the > time to think about how that library works, and how to be nice to the > machines that it will run on. So I'd better think a lot about optimizing my > code, and about helping my users get the best reactions from it. > > On Thu

Re: async/await -> await/async: a simpler, less error-prone async syntax

gi=170f198491b1 > - > > Isiah Meadows > m...@isiahmeadows.com > > Looking for web consulting? Or a new website? > Send me an email and we can get started. > www.isiahmeadows.com > > > On Tue, Dec 5, 2017 at 8:49 PM, kai zhu <kaizhu...@gmail.com>

Re: async/await -> await/async: a simpler, less error-prone async syntax

> On Dec 7, 2017, at 5:50 PM, Isiah Meadows wrote: > > The real solution to that would be stackful coroutines, but those are tricky > to implement and are substantially slower at lower nesting levels. (Go's > goroutines are built from this under the hood.) There's

Re: Identifying pure (or "pure within a scope") JavaScript functions?

> This led down a long, rambling path [1] where I then realized: if the > callback function is a pure function, then for the purposes of that callback, > the arguments probably do not need to be wrapped in proxies at all. The big > catch is that the callback can't store any of the arguments

Re: Since we're discussing arrow functions and syntax...

-1 this is user-hostile to c++ programmers writing wasm / node-native modules, when they context-switch c++ <-> javascript On 10/25/17, Michael Rosefield wrote: > I like arrow functions, and sometimes the only reason I don't use them is > because I need this-binding. > >

Re: Shorter syntax for arrow function assignment

-1 this fails styleguide sanity-check. we currently have 3 common styles of declaring functions: 1. foo = function () {...} 2. function foo () {...} 3. foo = () => {...} does this extra 4th style offer anything new to justify making the javascript language even less consistent than it already

Re: javascript vision thing

t; > Just use the one that's simpler to implement based on what your app is doing! > > To answer your question, yes I've done async with classes. It poses no additional challenge whatsoever. > > > On Wed, 20 Dec 2017, 8:44 am kai zhu, <kaizhu...@gmail.com> wrote: >> >&g

Re: Dynamic `import` with options

c39’s design-by-commitee process). kai zhu kaizhu...@gmail.com > On 9 May 2018, at 8:43 AM, Isiah Meadows <isiahmead...@gmail.com> wrote: > > Missed the list somehow... > > -- Forwarded message -- > From: Isiah Meadows <isiahmead...@gmail.com>

Re: Overload str.replace to take a Map?

= { '$': '^', '1': '2', '<': '', '': '', '-': '_', ']': '@' }; // output: "test_^^[22@ foo>" console.log('test-$$[11] '.replace((/[\S\s]/gu), function (character) { return dict.hasOwnProperty(character) ? dict[character] : character; })); ```

Re: Overload str.replace to take a Map?

hi mathias, i see... here's some simple, throwaway glue-code that does what i think you want. ```js /*jslint node: true */ 'use strict'; var text; text =

Re: Overload str.replace to take a Map?

.replace((/'/g), '') .replace((//g), '') .replace((/(amp;|apos;|gt;|lt;|quot;)/ig), '&$1'); } return value; }, 'templateRender could not render expression ' + JSON.stringify(match0) + '\n'); }); }; console.l

Re: [chromium-dev] ES6 in Chromium proposal: Allow modules

adding people from es-discuss@mozilla.org into the loop, to give us insight on the state of es6-module adoption. kai zhu kaizhu...@gmail.com > On 26 May 2018, at 3:52 AM, Jimmy Hastings <jhasti...@chromium.org> wrote: > > (Changing subject per dpapad's suggestion) >

Re: Overload str.replace to take a Map?

not a huge fan either, but here are 2 real-world non-frontend examples: the first is an excerpt from a backend-tool to automagically convert documentation from developers.github.com into swagger-docs [1]. its used to auto-generate nodejs-clients [2] for github’s ~300 apis, rather than doing it

Re: Adding support for enums

; case 'LOADING_SEARCH_RESULT': ... break; } ``` kai zhu kaizhu...@gmail.com > On 11 Jun 2018, at 3:50 AM, Nicolò Ribaudo wrote: > > Have you seen https://github.com/rbuckton/proposal-enum > <https://github.com/rbuckton/proposal-enum>? The champion is a TypeScript > member,

Re: Adding support for enums

criptive names that won’t collide (e.g. 'LOADING_SPINNER', ‘LOADING_SEARCH_RESULT'). kai zhu kaizhu...@gmail.com > On 10 Jun 2018, at 11:26 AM, Michael J. Ryan wrote: > > Just use symbols for your action type > > On Sat, Jun 9, 2018, 14:21 Doug Wade <mailto:douglas.b.w...@

Re: Shape objects

ot;statusCode": 400 } ``` [1] shape-validate integration-level interfaces with swagger https://kaizhu256.github.io/example-esdiscuss-topic-shape-objects/assets.swgg.html <https://kaizhu256.github.io/example-esdiscuss-topic-shape-objects/assets.swgg.html> kai zhu kaizhu...@gmail.com

Re: Adding support for enums

hi @peter, appreciate your perspective for embedded-device use-case. however, as @isiah mentions, there are existing javascript design-patterns using dicts/lists that are superior to enums. the primary reason (which was implied) is because they can be easily stored/shared/parsed as json

Re: Big integer, Big float, and operator overloading ideas

67890123456789e+123456 // takes ~200ms to process mjs > JSON.parse(JSON.stringify(1.12345678901234567890123456789e-123456)) 1.12345678901234567890123456789e-123456 // takes ~200ms to process mjs > JSON.stringify(1.1e1234567890) // unresponsive mjs > JSON.stringify(1.1e-1234567890) // u

Re: Big integer, Big float, and operator overloading ideas

oh, also i'm not a tc39 member if i made it sound like i was ^^;;; kai zhu kaizhu...@gmail.com > On 29 May 2018, at 1:43 AM, kai zhu wrote: > > hi fabrice, what you’ve done is interesting and impressive; but an > integration-level concern (if tc39 is to consider standa

Re: "Stupid" JSON Number Serialization Question

tps://github.com/whatwg/html/pull/3480> Addresses #230 <https://github.com/w3c/IndexedDB/issues/230> [1] github pull-request - Allow BigInts as IndexedDB keys #231 https://github.com/w3c/IndexedDB/pull/231 <https://github.com/w3c/IndexedDB/pull/231> > On 26 May 2018, at 11:4

Re: "Stupid" JSON Number Serialization Question

SON / .toString https://github.com/tc39/proposal-bigint/issues/124 <https://github.com/tc39/proposal-bigint/issues/124> kai zhu kaizhu...@gmail.com > On 20 May 2018, at 11:12 PM, Richard Gibson <richard.gib...@gmail.com> wrote: > > That seems like a question best addressed by

Re: Big integer, Big float, and operator overloading ideas

fy in bigint mode so that it does not throw an exception in >> case of a bigint value. >> Regarding the unresponsive cases you noticed with large exponents in >> floating point literals, it is a known problem of the current code which >> will be corrected. >> Best regards, >

Re: Symbol history

edition, June 1997 https://www.ecma-international.org/publications/files/ECMA-ST-ARCH/ECMA-262,%201st%20edition,%20June%201997.pdf <https://www.ecma-international.org/publications/files/ECMA-ST-ARCH/ECMA-262,%201st%20edition,%20June%201997.pdf> kai zhu kaizhu...@gmail.com > On 29 M

Re: [Proposal] New syntax for lazy getters

senior-programmers when they have to debug high-level integration-code that have problems baton-passing those states around. kai zhu kaizhu...@gmail.com > On 12 Jun 2018, at 9:07 PM, Isiah Meadows wrote: > > BTW, I proposed similar (lazy values) 9 months ago [1], and it's been > on

Re: Proposal: Conditional `catch` in Promises

; } return handleOtherErrors(reason)) // catch all others }); ``` kai zhu kaizhu...@gmail.com > > On Wed, Apr 25, 2018 at 10:25 PM, Bob Myers <r...@gol.com > <mailto:r...@gol.com>> wrote: > What do you mean by "approach TypeScript"? D

performance benchmark of async-design-patterns - recursive-callbacks vs. promises vs. async/await

break; default: if (error) { console.error(error); } local.exitCode = Number(!!error); local.templateRenderAndPrint('state {{state}} - process.exit({{exitCode}})'); process.exit(local.exitCode); } };

Re: How it feels to learn JavaScript in 2016

t;m...@heyimmark.com> wrote: > kai, what do you think would've been a better alternative? (Honestly > curious) > > On Fri, Oct 27, 2017 at 1:27 AM kai zhu <kaizhu...@gmail.com> wrote: > >> tc39 is partly to blame for promoting the perception of javascript >> langu

Re: How it feels to learn JavaScript in 2016

associated tooling, then don't use > them. > Meanwhile, other people will be using them to build reliable, > well-engineered, large-scale, performant applications. > Bob > > On Fri, Oct 27, 2017 at 10:57 AM, kai zhu <kaizhu...@gmail.com> wrote: > >> tc39 is partly

Re: How it feels to learn JavaScript in 2016

tc39 is partly to blame for promoting the perception of javascript language instability, which promotes tooling instability. generators, es modules, destructing, let, fat arrows have caused tremendous harm to tooling stability, which has made frontend-development hell for everyone. On 10/27/17,

Re: How it feels to learn JavaScript in 2016

e for 2018. if you're a product manager and your priority is to ship a frontend product, then your safest bet is to avoid es6 altogether. On 10/27/17, Naveen Chawla <naveen.c...@gmail.com> wrote: > kai zhu, it sounds like you have a bad manager who is over eagerly pushing > for a disruptiv

Re: Proposal: Optional Static Typing (Part 3)

e are the kinds of bugs that keep javascript-developers awake at night, not some kiddie string-instead-of-number type-error. > On Jan 14, 2018, at 12:48 AM, Pier Bover <pierbove...@gmail.com> wrote: > > I strongly disagree with kai zhu. > > where is this demand coming from?

Re: Proposal: Optional Static Typing (Part 3)

rant warning > The demand for types as a different approach to code has been so strong in > the past few years that separate languages have been created to deal with the > perceived shortcomings. where is this demand coming from? newcomers from c# / java who don't know anything about how

Re: Native Tensor support

for stuff like machine-learning, using web-assembly / asm.js on an existing c/c++ library is probably more practical than trying to roll your own in javascript. here are some pre-compiled (in asm.js) binaries using fann you can download and run directly in nodejs:

Re: Native Tensor support

> On Jan 28, 2018, at 10:58 PM, kai zhu <kaizhu...@gmail.com> wrote: > > for stuff like machine-learning, using web-assembly / asm.js on an existing > c/c++ library is probably more practical than trying to roll your own in > javascript. > > here are some pre-co

  1   2   3   >