tj.crowder at farsightsoftware.com
Tue Jul 24 10:56:22 UTC 2018
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
More information about the es-discuss