kaizhu256 at gmail.com
Wed Jul 25 10:33:47 UTC 2018
kaizhu256 at gmail.com
> On 24 Jul 2018, at 5:56 PM, T.J. Crowder <tj.crowder at farsightsoftware.com> wrote:
> On Tue, Jul 24, 2018 at 11:27 AM, kai zhu <kaizhu256 at gmail.com> wrote:
>> instead of wasting-time on hard-to-serialize classes/meta-programming.
> This is a false dichotomy (the fallacy of the either/or choice). I'd
> agree we're approaching, or at, the need for the next thing after
> JSON, and that some focus on that would be a good thing. That doesn't
> mean stopping work on other good things. Perhaps you could take the
> lead on addressing the issues you run into. I'm sure constructive
> input would be welcomed.
>> language (and try to design it as such), when industry-wise, its really not.
> Yes, it is. Just because you don't see it that way doesn't mean others
> don't. And others have been telling you they see it differently
> repeatedly over a long period of time on this list.
>> if tc39 is sincerely
>> they should focus on *practical* (vs *academic*) features
> `class` notation is practical (simplifying a common pattern and making
> it less error-prone). (I know you don't use that pattern. That's fine.
> But lots of people do, so it's practical for them whether you like the
> pattern or not.) Promises are practical (simplifying and standardizing
> callbacks, making them composable; again making them less
> error-prone). `async`/`await` is HUGELY practical, massively
> simplifying writing asynchronous code. Arrow functions, rest and
> spread, default parameter values -- all practical. (NOT trying to put
> words in your mouth, but if you were going to reply "Yes, but those
> problems could already be solved in others ways.", then: Sure, and we
> could all write assembly code, too. But it's *useful* to address these
> in the language.)
> All of them are useful beyond the web. All are also useful in web programming.
> I have no problem with skepticism of specific proposals. What I would
> find useful, though, would be a focus on the proposal's merits, rather
> language. You've made that claim, ad nauseum. My view is that it's
> been rejected by the list membership and by TC39, but whether that's
> true or I'm mistaken, please stop spamming the list with it. We all
> know how you feel about it.
> But again: I'm sure constructive, research-based input on how to deal
> with JSON issues related to (for instance) BigInt would be welcome in
> that BigInt thread and, ideally, eventually a proposal. There's no
> need for some big conceptual argument over the course of the language
> -- that *is* a waste of time.
> -- T.J. Crowder
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss