javascript vision thing

classic Classic list List threaded Threaded
87 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: [nodejs] Re: javascript vision thing

kai zhu
this is not a troll-account, and I’m a live-person with realistic (albeit uncomfortable) views on limitations of javascript product-development in industry.

es6 seems to adopt java’s philosophy that with careful-planning, you can create semi-permanent, well-abstracted code during the design-phase that will last throughout the product-development cycle.  my experience with numerous web-projects, both successful and failed, indicates this approach as flawed.  and i believe most people in industry who have been burned by failed web-projects in the past (due to over-encumbered/engineered initial-designs that couldn’t cope with realities of product integration/qa) are wary of hiring unproven java-turned-js devs who still hold these brittle design-philosophies.

there's no such thing as “permanent” javascript-code in product-development.  everything eventually gets rewritten, when the inevitable business-critical ux feature-request comes in that you must accommodate, even though it breaks your current integration-workflow.  when this common scenario plays out in industry:

a) the [inexperienced] unqualified js-dev likely dithers, unwilling/unable to unwind the complicated initial-design they architected to accommodate the feature-request, while
b) the [experienced] qualified js-dev would have anticipated this, and simply rewrites their initial expendable-code with new expendable-code to accommodate the feature-request (with expectation it will be rewritten again-and-again in the future).

its difficult for employers to discern whether js-devs will exhibit trait a) or trait b) through technical-interview alone.  and es6 skews this with design-patterns biased towards trait a), further confusing employers seeking qualified js-devs.


On 23 Sep 2018, at 1:43 AM, Zlatko Đurić <[hidden email]> wrote:

Hi all,

I don't know why I can't resist this troll. I've just spent half an hour writing an elaborate answer on how the whole premise is wrong, knowing that this is a known troll account. Well, I've deleted it all and will not fall for his trolling again.

 (Btw I thought this list is moderated, how come his same-all troll ramblings always pass the mods?)

Zlatko 

On Sat 22. Sep 2018 at 18:26, Michael J. Ryan <[hidden email]> wrote:
Considering how many js devs fail to answer "what values evaluate to false in JavaScript". It isn't the new features that are the problem.

There's a combination of problems.  People believing they're better developers than they are.  People who look down on js and front end development.  And those ahead to learn new things.

JS isn't really evolving any more than Java, C#, go, python and others as a whole in the past 20 years.  And having to fight uphill to use newer features is a pain.  I'm not on the younger side of this (I'm 42)... But I've managed to keep up.

On Fri, Sep 21, 2018, 17:14 kai zhu <[hidden email]> wrote:
a problem i've observed in industry is that many es6 language-features have the unintended-consequence of incentivising incompetent javascript-developers at the expense of competent-ones.  its generally difficult for many employers (even those knowledgeable in general-purpose programming), to discern between:

a) a competent javascript employee/contractor who can get things done and ship products (albeit with legitimate delays), and
b) an incompetent-one who can easily hide themselves in non-productive es6 busywork, and continually pushback product-integration (again with “legitimate” delays, until its too late).

its gotten bad enough that many industry-employers no longer trust general-purpose-programming technical-interviews when recruiting js-devs, and rely almost exclusively on either a) an applicant's reputation / word-of-mouth for getting things done, or b) their ability to complete a time-consuming tech-challenge, where they must demonstrate ability to ship a mini-product.  both methods are not scalable to meet the demand in industry for qualified js-devs in product-development.

the only solution i can think of to this industry-problem is to hold-back on introducing new disruptive/unproven javascript design-patterns, and figuring out how to educate the industry with tightened javascript style-guides and existing design-patterns proven to work (more is less); generally, ways to enhance the current, woefully inadequate “bullsh*t detector” of employers so they can better identify and mentor/train/weed-out unqualified js-devs.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

--
Job board: http://jobs.nodejs.org/
New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
---
You received this message because you are subscribed to a topic in the Google Groups "nodejs" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/nodejs/p81p-_FqS-s/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/CA%2BpgmMoRmv-P-8a%2B6JCj8szBcJ_32fPULL3DqrZp%2B3SgMZLTDw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
Zlatko


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [nodejs] Re: javascript vision thing

Henrique Barcelos
In reply to this post by kai zhu
> 1. es6 generators and modules are the top 2 notorious things that come to mind as being difficult to debug/integrate in product-development.

How exactly are generators and modules difficult to integrate or debug? Difficult compared to what?

How are ES modules more complicated for the developer than CommonJS or UMD?

How come generators be more complex than handling a sequence of asynchronous code using a user-land event-based API?

How difficult would it be for Javascript engines to optimize user-land code?

> 2. classes (and typescript, though not directly es6-related), tend to create lots of unnecessary structure that becomes a PITA when you need to rewrite everything, which occurs often in product-development. there are lots of newly minted js-devs entering industry, who lack experience in understanding the risks of javascript over-engineering (and that nothing you write is permanent). they write lots of semi-permanent, es6 infrastructure-code during the initial design-phase, which is a general no-no for many veterans, who understand most of that stuff is going to get tossed out the window and rewritten during integration-phase (and again everytime a ux feature-request comes in that breaks the existing integration-workflow).

What exactly is this related to classes? While I myself am not a fan of the whole classical syntactic sugar on top of prototypal chains, it's not the language's fault that its features are frequently abused and misused.

What you're saying about over-engineering is not intrinsic to the Javascript community, it's a software engineering problem.

Maybe it's because we work in a new field, with roughly 50 years (although programming itself has changed a lot since the 60's). Maybe it's because we're forming bad developers. Maybe it's because software development is a really complex subject.

One thing we can know for sure is that the tools are not the problem. We are. You can use a knife to cook a delicious meal, by you can also use it to kill someone.

> 3. let and const declarations. most code you debug/write in javascript is ux-related integration-code dealing with async-io, which relies heavily on function-scoped closures to pass variables across process-ticks. block-level scoping is an unnecessary design-pattern that leads to confusion over the former.

This is an odd complaint, because variable hoisting was one of the more convoluted features of Javascript, simply because it was different from any other language I've heard of.

I don't think you could even call block-level scoping a "design pattern", because it is a de facto standard for modern languages.

Em sáb, 22 de set de 2018 04:42, kai zhu <[hidden email]> escreveu:
yes, in order of severity:

1. es6 generators and modules are the top 2 notorious things that come to mind as being difficult to debug/integrate in product-development.

2. classes (and typescript, though not directly es6-related), tend to create lots of unnecessary structure that becomes a PITA when you need to rewrite everything, which occurs often in product-development.  there are lots of newly minted js-devs entering industry, who lack experience in understanding the risks of javascript over-engineering (and that nothing you write is permanent).  they write lots of semi-permanent, es6 infrastructure-code during the initial design-phase, which is a general no-no for many veterans, who understand most of that stuff is going to get tossed out the window and rewritten during integration-phase (and again everytime a ux feature-request comes in that breaks the existing integration-workflow).

3. let and const declarations.  most code you debug/write in javascript is ux-related integration-code dealing with async-io, which relies heavily on function-scoped closures to pass variables across process-ticks.  block-level scoping is an unnecessary design-pattern that leads to confusion over the former.

4. fat-arrow.  it has garden-path issues, making it difficult to write efficient javascript-parsers that can differentiate the following [valid] javascript-code:
```js
(aa = 1, bb = 2, cc = 3);
// vs
(aa = 1, bb = 2, cc = 3) => aa + bb;
```
this leads to fundamental performance-issues with tooling/minification/test-coverage-instrumenters.  jslint for efficiency-reasons, simply cheats and assumes both of the above are fat-arrows, and raises fat-arrow warnings for both (and halts further parsing) [1].

[1] jslint managing garden-path complexity of fat-arrow, with a single lookahead, that can turn out wrong, so it halts parsing.


On 22 Sep 2018, at 12:04 PM, Siegfried Bilstein <[hidden email]> wrote:

Do you have examples of the patterns and es6 features you describe? 

Siggy

On Sat, Sep 22, 2018 at 01:02 kai zhu <[hidden email]> wrote:
a problem i've observed in industry is that many es6 language-features have the unintended-consequence of incentivising incompetent javascript-developers at the expense of competent-ones.  its generally difficult for many employers (even those knowledgeable in general-purpose programming), to discern between:

a) a competent javascript employee/contractor who can get things done and ship products (albeit with legitimate delays), and
b) an incompetent-one who can easily hide themselves in non-productive es6 busywork, and continually pushback product-integration (again with “legitimate” delays, until its too late).

its gotten bad enough that many industry-employers no longer trust general-purpose-programming technical-interviews when recruiting js-devs, and rely almost exclusively on either a) an applicant's reputation / word-of-mouth for getting things done, or b) their ability to complete a time-consuming tech-challenge, where they must demonstrate ability to ship a mini-product.  both methods are not scalable to meet the demand in industry for qualified js-devs in product-development.

the only solution i can think of to this industry-problem is to hold-back on introducing new disruptive/unproven javascript design-patterns, and figuring out how to educate the industry with tightened javascript style-guides and existing design-patterns proven to work (more is less); generally, ways to enhance the current, woefully inadequate “bullsh*t detector” of employers so they can better identify and mentor/train/weed-out unqualified js-devs.

--
Job board: http://jobs.nodejs.org/
New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/0BBA242B-D57D-4260-BC24-7983923B43A7%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
Sent from Gmail Mobile

--
Job board: http://jobs.nodejs.org/
New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/CAOd5ZkpWCKLTk9TR%2BeE%2Bg9upuezAf_EQVKnpaOhFNk1SgYiZJA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
--

Henrique


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [nodejs] Re: javascript vision thing

Naveen Chawla
In reply to this post by kai zhu
ES6 doesn't encourage any design patterns. All it does is allow you to shorten existing constructs into simpler-to-program ones, and simpler-to-understand ones. I want TC39 to continue in this vein, making big things easier to accomplish with less, hence, speeding up development time (very important) and reducing the surface area for potential bugs (also very important). And, I want them to be very aggressive (fast) in this regard

On Sun, 23 Sep 2018 at 07:15 kai zhu <[hidden email]> wrote:
this is not a troll-account, and I’m a live-person with realistic (albeit uncomfortable) views on limitations of javascript product-development in industry.

es6 seems to adopt java’s philosophy that with careful-planning, you can create semi-permanent, well-abstracted code during the design-phase that will last throughout the product-development cycle.  my experience with numerous web-projects, both successful and failed, indicates this approach as flawed.  and i believe most people in industry who have been burned by failed web-projects in the past (due to over-encumbered/engineered initial-designs that couldn’t cope with realities of product integration/qa) are wary of hiring unproven java-turned-js devs who still hold these brittle design-philosophies.

there's no such thing as “permanent” javascript-code in product-development.  everything eventually gets rewritten, when the inevitable business-critical ux feature-request comes in that you must accommodate, even though it breaks your current integration-workflow.  when this common scenario plays out in industry:

a) the [inexperienced] unqualified js-dev likely dithers, unwilling/unable to unwind the complicated initial-design they architected to accommodate the feature-request, while
b) the [experienced] qualified js-dev would have anticipated this, and simply rewrites their initial expendable-code with new expendable-code to accommodate the feature-request (with expectation it will be rewritten again-and-again in the future).

its difficult for employers to discern whether js-devs will exhibit trait a) or trait b) through technical-interview alone.  and es6 skews this with design-patterns biased towards trait a), further confusing employers seeking qualified js-devs.


On 23 Sep 2018, at 1:43 AM, Zlatko Đurić <[hidden email]> wrote:

Hi all,

I don't know why I can't resist this troll. I've just spent half an hour writing an elaborate answer on how the whole premise is wrong, knowing that this is a known troll account. Well, I've deleted it all and will not fall for his trolling again.

 (Btw I thought this list is moderated, how come his same-all troll ramblings always pass the mods?)

Zlatko 

On Sat 22. Sep 2018 at 18:26, Michael J. Ryan <[hidden email]> wrote:
Considering how many js devs fail to answer "what values evaluate to false in JavaScript". It isn't the new features that are the problem.

There's a combination of problems.  People believing they're better developers than they are.  People who look down on js and front end development.  And those ahead to learn new things.

JS isn't really evolving any more than Java, C#, go, python and others as a whole in the past 20 years.  And having to fight uphill to use newer features is a pain.  I'm not on the younger side of this (I'm 42)... But I've managed to keep up.

On Fri, Sep 21, 2018, 17:14 kai zhu <[hidden email]> wrote:
a problem i've observed in industry is that many es6 language-features have the unintended-consequence of incentivising incompetent javascript-developers at the expense of competent-ones.  its generally difficult for many employers (even those knowledgeable in general-purpose programming), to discern between:

a) a competent javascript employee/contractor who can get things done and ship products (albeit with legitimate delays), and
b) an incompetent-one who can easily hide themselves in non-productive es6 busywork, and continually pushback product-integration (again with “legitimate” delays, until its too late).

its gotten bad enough that many industry-employers no longer trust general-purpose-programming technical-interviews when recruiting js-devs, and rely almost exclusively on either a) an applicant's reputation / word-of-mouth for getting things done, or b) their ability to complete a time-consuming tech-challenge, where they must demonstrate ability to ship a mini-product.  both methods are not scalable to meet the demand in industry for qualified js-devs in product-development.

the only solution i can think of to this industry-problem is to hold-back on introducing new disruptive/unproven javascript design-patterns, and figuring out how to educate the industry with tightened javascript style-guides and existing design-patterns proven to work (more is less); generally, ways to enhance the current, woefully inadequate “bullsh*t detector” of employers so they can better identify and mentor/train/weed-out unqualified js-devs.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

--
Job board: http://jobs.nodejs.org/
New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
---
You received this message because you are subscribed to a topic in the Google Groups "nodejs" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/nodejs/p81p-_FqS-s/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [hidden email].

To post to this group, send email to [hidden email].

For more options, visit https://groups.google.com/d/optout.
--
Zlatko
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [nodejs] Re: javascript vision thing

Henrique Barcelos
In reply to this post by Henrique Barcelos
> 1. es6 generators and modules are the top 2 notorious things that come to mind as being difficult to debug/integrate in product-development.

How exactly are generators and modules difficult to integrate or debug? Difficult compared to what?

How are ES modules more complicated for the developer than CommonJS or UMD?

How come generators be more complex than handling a sequence of asynchronous code using a user-land event-based API?

How difficult would it be for Javascript engines to optimize user-land code?

To me, it's far better to have something in the language's standard lib that a user-land implementation, specially for beginners.

> 2. classes (and typescript, though not directly es6-related), tend to create lots of unnecessary structure that becomes a PITA when you need to rewrite everything, which occurs often in product-development. there are lots of newly minted js-devs entering industry, who lack experience in understanding the risks of javascript over-engineering (and that nothing you write is permanent). they write lots of semi-permanent, es6 infrastructure-code during the initial design-phase, which is a general no-no for many veterans, who understand most of that stuff is going to get tossed out the window and rewritten during integration-phase (and again everytime a ux feature-request comes in that breaks the existing integration-workflow).

What exactly is this related to classes? While I myself am not a fan of the whole classical syntactic sugar on top of prototypal chains, it's not the language's fault that its features are frequently abused and misused.

What you're saying about over-engineering is not intrinsic to the Javascript community, it's a software engineering problem.

Maybe it's because we work in a new field, with roughly 50 years (although programming itself has changed a lot since the 60's). Maybe it's because we're forming bad developers. Maybe it's because software development is a really complex subject.

One thing we can know for sure is that the tools are not the problem. We are. You can use a knife to cook a delicious meal, by you can also use it to kill someone.

> 3. let and const declarations. most code you debug/write in javascript is ux-related integration-code dealing with async-io, which relies heavily on function-scoped closures to pass variables across process-ticks. block-level scoping is an unnecessary design-pattern that leads to confusion over the former.

This is an odd complaint, because variable hoisting was one of the more convoluted features of Javascript, simply because it was different from any other language I've heard of.

I don't think you could even call block-level scoping a "design pattern", because it is a de facto standard for modern languages.

> 4. fat-arrow. it has garden-path issues, making it difficult to write efficient javascript-parsers that can differentiate the following [valid] javascript-code:
>```js
(aa = 1, bb = 2, cc = 3);
// vs
(aa = 1, bb = 2, cc = 3) => aa + bb;
```
>this leads to fundamental performance-issues with tooling/minification/test-coverage-instrumenters. jslint for efficiency-reasons, simply cheats and assumes both of the above are fat-arrows, and raises fat-arrow warnings for both (and halts further parsing) [1].

I have never written or seen code like `(aa = 1, bb = 2, cc = 3)`. If you code like that, you're the problem, not JavaScript. Even though it's a valid construct, for compatibility sake, it doesn't mean that modern tools should support or endorse this.

"Oh, but performance...". Yeah, you can also write a perfectly valid code that hurts performance as well. You can even create an infinite loop with valid constructs. It doesn't mean you should.

---

Summarizing what I'm trying to say: your criticism has nothing to do with the language or its evolution pace. They are universal problems around software engineering and will continue to be even if we slowed down.

I've been writing Javascript code since ES3 and my life got significantly better with ES6+.

The existence of TC39 guarantees that a feature will only make it into the language after a very thorough public scrutiny process.

I don't believe we need to go slower. In fact, I wish we could move even faster.


Em dom, 23 de set de 2018 01:32, Henrique Barcelos <[hidden email]> escreveu:
> 1. es6 generators and modules are the top 2 notorious things that come to mind as being difficult to debug/integrate in product-development.

How exactly are generators and modules difficult to integrate or debug? Difficult compared to what?

How are ES modules more complicated for the developer than CommonJS or UMD?

How come generators be more complex than handling a sequence of asynchronous code using a user-land event-based API?

How difficult would it be for Javascript engines to optimize user-land code?

> 2. classes (and typescript, though not directly es6-related), tend to create lots of unnecessary structure that becomes a PITA when you need to rewrite everything, which occurs often in product-development. there are lots of newly minted js-devs entering industry, who lack experience in understanding the risks of javascript over-engineering (and that nothing you write is permanent). they write lots of semi-permanent, es6 infrastructure-code during the initial design-phase, which is a general no-no for many veterans, who understand most of that stuff is going to get tossed out the window and rewritten during integration-phase (and again everytime a ux feature-request comes in that breaks the existing integration-workflow).

What exactly is this related to classes? While I myself am not a fan of the whole classical syntactic sugar on top of prototypal chains, it's not the language's fault that its features are frequently abused and misused.

What you're saying about over-engineering is not intrinsic to the Javascript community, it's a software engineering problem.

Maybe it's because we work in a new field, with roughly 50 years (although programming itself has changed a lot since the 60's). Maybe it's because we're forming bad developers. Maybe it's because software development is a really complex subject.

One thing we can know for sure is that the tools are not the problem. We are. You can use a knife to cook a delicious meal, by you can also use it to kill someone.

> 3. let and const declarations. most code you debug/write in javascript is ux-related integration-code dealing with async-io, which relies heavily on function-scoped closures to pass variables across process-ticks. block-level scoping is an unnecessary design-pattern that leads to confusion over the former.

This is an odd complaint, because variable hoisting was one of the more convoluted features of Javascript, simply because it was different from any other language I've heard of.

I don't think you could even call block-level scoping a "design pattern", because it is a de facto standard for modern languages.

Em sáb, 22 de set de 2018 04:42, kai zhu <[hidden email]> escreveu:
yes, in order of severity:

1. es6 generators and modules are the top 2 notorious things that come to mind as being difficult to debug/integrate in product-development.

2. classes (and typescript, though not directly es6-related), tend to create lots of unnecessary structure that becomes a PITA when you need to rewrite everything, which occurs often in product-development.  there are lots of newly minted js-devs entering industry, who lack experience in understanding the risks of javascript over-engineering (and that nothing you write is permanent).  they write lots of semi-permanent, es6 infrastructure-code during the initial design-phase, which is a general no-no for many veterans, who understand most of that stuff is going to get tossed out the window and rewritten during integration-phase (and again everytime a ux feature-request comes in that breaks the existing integration-workflow).

3. let and const declarations.  most code you debug/write in javascript is ux-related integration-code dealing with async-io, which relies heavily on function-scoped closures to pass variables across process-ticks.  block-level scoping is an unnecessary design-pattern that leads to confusion over the former.

4. fat-arrow.  it has garden-path issues, making it difficult to write efficient javascript-parsers that can differentiate the following [valid] javascript-code:
```js
(aa = 1, bb = 2, cc = 3);
// vs
(aa = 1, bb = 2, cc = 3) => aa + bb;
```
this leads to fundamental performance-issues with tooling/minification/test-coverage-instrumenters.  jslint for efficiency-reasons, simply cheats and assumes both of the above are fat-arrows, and raises fat-arrow warnings for both (and halts further parsing) [1].

[1] jslint managing garden-path complexity of fat-arrow, with a single lookahead, that can turn out wrong, so it halts parsing.


On 22 Sep 2018, at 12:04 PM, Siegfried Bilstein <[hidden email]> wrote:

Do you have examples of the patterns and es6 features you describe? 

Siggy

On Sat, Sep 22, 2018 at 01:02 kai zhu <[hidden email]> wrote:
a problem i've observed in industry is that many es6 language-features have the unintended-consequence of incentivising incompetent javascript-developers at the expense of competent-ones.  its generally difficult for many employers (even those knowledgeable in general-purpose programming), to discern between:

a) a competent javascript employee/contractor who can get things done and ship products (albeit with legitimate delays), and
b) an incompetent-one who can easily hide themselves in non-productive es6 busywork, and continually pushback product-integration (again with “legitimate” delays, until its too late).

its gotten bad enough that many industry-employers no longer trust general-purpose-programming technical-interviews when recruiting js-devs, and rely almost exclusively on either a) an applicant's reputation / word-of-mouth for getting things done, or b) their ability to complete a time-consuming tech-challenge, where they must demonstrate ability to ship a mini-product.  both methods are not scalable to meet the demand in industry for qualified js-devs in product-development.

the only solution i can think of to this industry-problem is to hold-back on introducing new disruptive/unproven javascript design-patterns, and figuring out how to educate the industry with tightened javascript style-guides and existing design-patterns proven to work (more is less); generally, ways to enhance the current, woefully inadequate “bullsh*t detector” of employers so they can better identify and mentor/train/weed-out unqualified js-devs.

--
Job board: http://jobs.nodejs.org/
New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/0BBA242B-D57D-4260-BC24-7983923B43A7%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
Sent from Gmail Mobile

--
Job board: http://jobs.nodejs.org/
New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/CAOd5ZkpWCKLTk9TR%2BeE%2Bg9upuezAf_EQVKnpaOhFNk1SgYiZJA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
--

Henrique

--

Henrique


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [nodejs] Re: javascript vision thing

Ben Wiley
I find the general tone of the preceding thread condescending toward developers who have dealt with real problems recent ES additions have addressed. Though I don't think I totally follow your argument that continuing to increase API surface area decreases the surface area for bugs. Perhaps for the developer, but certainly not for the core platform which browsers have to implement. Also as there's a trend toward demand for more and more language-inherent ways to accomplish the same thing, I think we're beginning to overload newcomers to the language with grammar to learn.

Ben

Le dim. 23 sept. 2018 00 h 51, Henrique Barcelos <[hidden email]> a écrit :
> 1. es6 generators and modules are the top 2 notorious things that come to mind as being difficult to debug/integrate in product-development.

How exactly are generators and modules difficult to integrate or debug? Difficult compared to what?

How are ES modules more complicated for the developer than CommonJS or UMD?

How come generators be more complex than handling a sequence of asynchronous code using a user-land event-based API?

How difficult would it be for Javascript engines to optimize user-land code?

To me, it's far better to have something in the language's standard lib that a user-land implementation, specially for beginners.

> 2. classes (and typescript, though not directly es6-related), tend to create lots of unnecessary structure that becomes a PITA when you need to rewrite everything, which occurs often in product-development. there are lots of newly minted js-devs entering industry, who lack experience in understanding the risks of javascript over-engineering (and that nothing you write is permanent). they write lots of semi-permanent, es6 infrastructure-code during the initial design-phase, which is a general no-no for many veterans, who understand most of that stuff is going to get tossed out the window and rewritten during integration-phase (and again everytime a ux feature-request comes in that breaks the existing integration-workflow).

What exactly is this related to classes? While I myself am not a fan of the whole classical syntactic sugar on top of prototypal chains, it's not the language's fault that its features are frequently abused and misused.

What you're saying about over-engineering is not intrinsic to the Javascript community, it's a software engineering problem.

Maybe it's because we work in a new field, with roughly 50 years (although programming itself has changed a lot since the 60's). Maybe it's because we're forming bad developers. Maybe it's because software development is a really complex subject.

One thing we can know for sure is that the tools are not the problem. We are. You can use a knife to cook a delicious meal, by you can also use it to kill someone.

> 3. let and const declarations. most code you debug/write in javascript is ux-related integration-code dealing with async-io, which relies heavily on function-scoped closures to pass variables across process-ticks. block-level scoping is an unnecessary design-pattern that leads to confusion over the former.

This is an odd complaint, because variable hoisting was one of the more convoluted features of Javascript, simply because it was different from any other language I've heard of.

I don't think you could even call block-level scoping a "design pattern", because it is a de facto standard for modern languages.

> 4. fat-arrow. it has garden-path issues, making it difficult to write efficient javascript-parsers that can differentiate the following [valid] javascript-code:
>```js
(aa = 1, bb = 2, cc = 3);
// vs
(aa = 1, bb = 2, cc = 3) => aa + bb;
```
>this leads to fundamental performance-issues with tooling/minification/test-coverage-instrumenters. jslint for efficiency-reasons, simply cheats and assumes both of the above are fat-arrows, and raises fat-arrow warnings for both (and halts further parsing) [1].

I have never written or seen code like `(aa = 1, bb = 2, cc = 3)`. If you code like that, you're the problem, not JavaScript. Even though it's a valid construct, for compatibility sake, it doesn't mean that modern tools should support or endorse this.

"Oh, but performance...". Yeah, you can also write a perfectly valid code that hurts performance as well. You can even create an infinite loop with valid constructs. It doesn't mean you should.

---

Summarizing what I'm trying to say: your criticism has nothing to do with the language or its evolution pace. They are universal problems around software engineering and will continue to be even if we slowed down.

I've been writing Javascript code since ES3 and my life got significantly better with ES6+.

The existence of TC39 guarantees that a feature will only make it into the language after a very thorough public scrutiny process.

I don't believe we need to go slower. In fact, I wish we could move even faster.


Em dom, 23 de set de 2018 01:32, Henrique Barcelos <[hidden email]> escreveu:
> 1. es6 generators and modules are the top 2 notorious things that come to mind as being difficult to debug/integrate in product-development.

How exactly are generators and modules difficult to integrate or debug? Difficult compared to what?

How are ES modules more complicated for the developer than CommonJS or UMD?

How come generators be more complex than handling a sequence of asynchronous code using a user-land event-based API?

How difficult would it be for Javascript engines to optimize user-land code?

> 2. classes (and typescript, though not directly es6-related), tend to create lots of unnecessary structure that becomes a PITA when you need to rewrite everything, which occurs often in product-development. there are lots of newly minted js-devs entering industry, who lack experience in understanding the risks of javascript over-engineering (and that nothing you write is permanent). they write lots of semi-permanent, es6 infrastructure-code during the initial design-phase, which is a general no-no for many veterans, who understand most of that stuff is going to get tossed out the window and rewritten during integration-phase (and again everytime a ux feature-request comes in that breaks the existing integration-workflow).

What exactly is this related to classes? While I myself am not a fan of the whole classical syntactic sugar on top of prototypal chains, it's not the language's fault that its features are frequently abused and misused.

What you're saying about over-engineering is not intrinsic to the Javascript community, it's a software engineering problem.

Maybe it's because we work in a new field, with roughly 50 years (although programming itself has changed a lot since the 60's). Maybe it's because we're forming bad developers. Maybe it's because software development is a really complex subject.

One thing we can know for sure is that the tools are not the problem. We are. You can use a knife to cook a delicious meal, by you can also use it to kill someone.

> 3. let and const declarations. most code you debug/write in javascript is ux-related integration-code dealing with async-io, which relies heavily on function-scoped closures to pass variables across process-ticks. block-level scoping is an unnecessary design-pattern that leads to confusion over the former.

This is an odd complaint, because variable hoisting was one of the more convoluted features of Javascript, simply because it was different from any other language I've heard of.

I don't think you could even call block-level scoping a "design pattern", because it is a de facto standard for modern languages.

Em sáb, 22 de set de 2018 04:42, kai zhu <[hidden email]> escreveu:
yes, in order of severity:

1. es6 generators and modules are the top 2 notorious things that come to mind as being difficult to debug/integrate in product-development.

2. classes (and typescript, though not directly es6-related), tend to create lots of unnecessary structure that becomes a PITA when you need to rewrite everything, which occurs often in product-development.  there are lots of newly minted js-devs entering industry, who lack experience in understanding the risks of javascript over-engineering (and that nothing you write is permanent).  they write lots of semi-permanent, es6 infrastructure-code during the initial design-phase, which is a general no-no for many veterans, who understand most of that stuff is going to get tossed out the window and rewritten during integration-phase (and again everytime a ux feature-request comes in that breaks the existing integration-workflow).

3. let and const declarations.  most code you debug/write in javascript is ux-related integration-code dealing with async-io, which relies heavily on function-scoped closures to pass variables across process-ticks.  block-level scoping is an unnecessary design-pattern that leads to confusion over the former.

4. fat-arrow.  it has garden-path issues, making it difficult to write efficient javascript-parsers that can differentiate the following [valid] javascript-code:
```js
(aa = 1, bb = 2, cc = 3);
// vs
(aa = 1, bb = 2, cc = 3) => aa + bb;
```
this leads to fundamental performance-issues with tooling/minification/test-coverage-instrumenters.  jslint for efficiency-reasons, simply cheats and assumes both of the above are fat-arrows, and raises fat-arrow warnings for both (and halts further parsing) [1].

[1] jslint managing garden-path complexity of fat-arrow, with a single lookahead, that can turn out wrong, so it halts parsing.


On 22 Sep 2018, at 12:04 PM, Siegfried Bilstein <[hidden email]> wrote:

Do you have examples of the patterns and es6 features you describe? 

Siggy

On Sat, Sep 22, 2018 at 01:02 kai zhu <[hidden email]> wrote:
a problem i've observed in industry is that many es6 language-features have the unintended-consequence of incentivising incompetent javascript-developers at the expense of competent-ones.  its generally difficult for many employers (even those knowledgeable in general-purpose programming), to discern between:

a) a competent javascript employee/contractor who can get things done and ship products (albeit with legitimate delays), and
b) an incompetent-one who can easily hide themselves in non-productive es6 busywork, and continually pushback product-integration (again with “legitimate” delays, until its too late).

its gotten bad enough that many industry-employers no longer trust general-purpose-programming technical-interviews when recruiting js-devs, and rely almost exclusively on either a) an applicant's reputation / word-of-mouth for getting things done, or b) their ability to complete a time-consuming tech-challenge, where they must demonstrate ability to ship a mini-product.  both methods are not scalable to meet the demand in industry for qualified js-devs in product-development.

the only solution i can think of to this industry-problem is to hold-back on introducing new disruptive/unproven javascript design-patterns, and figuring out how to educate the industry with tightened javascript style-guides and existing design-patterns proven to work (more is less); generally, ways to enhance the current, woefully inadequate “bullsh*t detector” of employers so they can better identify and mentor/train/weed-out unqualified js-devs.

--
Job board: http://jobs.nodejs.org/
New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/0BBA242B-D57D-4260-BC24-7983923B43A7%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
Sent from Gmail Mobile

--
Job board: http://jobs.nodejs.org/
New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/CAOd5ZkpWCKLTk9TR%2BeE%2Bg9upuezAf_EQVKnpaOhFNk1SgYiZJA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
--

Henrique

--

Henrique

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [nodejs] Re: javascript vision thing

Isiah Meadows-2
(Not TC39 or a list admin, so please don't take this as authoritative by any means. These are all my personal opinions and mine only.)

To add onto this, could you all maybe take the complaints and general software discussion to Reddit, Twitter, private emails, or elsewhere? Philosophizing about JS is on-topic, but picking apart JS features to trash without adequate explanation isn't exactly philosophizing, and general language-independent complaints about the software industry are pretty off-topic when they have little-to-nothing to do with JS, and I'm not exactly seeing much connecting them to JS in some of these emails.

I've lately been observing more than actually discussing, but after being subscribed for about 3-4 years alternating between observing and actually contributing to this mailing list, I'd rather not have to unsubscribe because people persistently generating unproductive/off-topic content. This isn't even the first thread I've noted having these kinds of issues - a series of proposals about a few months ago made by someone trying to turn JS into a haphazard form of Prolog were no better than this, and I've seen quite a few other proposals here since that were also under-investigated before being proposed here. I've seen a few semi-recent gems come from here, such as with pattern matching and the `using` statement, but these seem to me to be becoming fewer and farther between, becoming the exception, not the norm.

I really don't like the direction this mailing list is going, and I hope it some day gets better. But my hopes for this happening are fading quickly, and much of this thread really isn't helping. I see a lot of condescension and animosity from multiple authors (not naming names), both towards each other and towards other developers in general. Could we please do without that?

Sorry for the long-winded rant.

On Sun, Sep 23, 2018 at 01:04 Ben Wiley <[hidden email]> wrote:
I find the general tone of the preceding thread condescending toward developers who have dealt with real problems recent ES additions have addressed. Though I don't think I totally follow your argument that continuing to increase API surface area decreases the surface area for bugs. Perhaps for the developer, but certainly not for the core platform which browsers have to implement. Also as there's a trend toward demand for more and more language-inherent ways to accomplish the same thing, I think we're beginning to overload newcomers to the language with grammar to learn.

Ben

Le dim. 23 sept. 2018 00 h 51, Henrique Barcelos <[hidden email]> a écrit :
> 1. es6 generators and modules are the top 2 notorious things that come to mind as being difficult to debug/integrate in product-development.

How exactly are generators and modules difficult to integrate or debug? Difficult compared to what?

How are ES modules more complicated for the developer than CommonJS or UMD?

How come generators be more complex than handling a sequence of asynchronous code using a user-land event-based API?

How difficult would it be for Javascript engines to optimize user-land code?

To me, it's far better to have something in the language's standard lib that a user-land implementation, specially for beginners.

> 2. classes (and typescript, though not directly es6-related), tend to create lots of unnecessary structure that becomes a PITA when you need to rewrite everything, which occurs often in product-development. there are lots of newly minted js-devs entering industry, who lack experience in understanding the risks of javascript over-engineering (and that nothing you write is permanent). they write lots of semi-permanent, es6 infrastructure-code during the initial design-phase, which is a general no-no for many veterans, who understand most of that stuff is going to get tossed out the window and rewritten during integration-phase (and again everytime a ux feature-request comes in that breaks the existing integration-workflow).

What exactly is this related to classes? While I myself am not a fan of the whole classical syntactic sugar on top of prototypal chains, it's not the language's fault that its features are frequently abused and misused.

What you're saying about over-engineering is not intrinsic to the Javascript community, it's a software engineering problem.

Maybe it's because we work in a new field, with roughly 50 years (although programming itself has changed a lot since the 60's). Maybe it's because we're forming bad developers. Maybe it's because software development is a really complex subject.

One thing we can know for sure is that the tools are not the problem. We are. You can use a knife to cook a delicious meal, by you can also use it to kill someone.

> 3. let and const declarations. most code you debug/write in javascript is ux-related integration-code dealing with async-io, which relies heavily on function-scoped closures to pass variables across process-ticks. block-level scoping is an unnecessary design-pattern that leads to confusion over the former.

This is an odd complaint, because variable hoisting was one of the more convoluted features of Javascript, simply because it was different from any other language I've heard of.

I don't think you could even call block-level scoping a "design pattern", because it is a de facto standard for modern languages.

> 4. fat-arrow. it has garden-path issues, making it difficult to write efficient javascript-parsers that can differentiate the following [valid] javascript-code:
>```js
(aa = 1, bb = 2, cc = 3);
// vs
(aa = 1, bb = 2, cc = 3) => aa + bb;
```
>this leads to fundamental performance-issues with tooling/minification/test-coverage-instrumenters. jslint for efficiency-reasons, simply cheats and assumes both of the above are fat-arrows, and raises fat-arrow warnings for both (and halts further parsing) [1].

I have never written or seen code like `(aa = 1, bb = 2, cc = 3)`. If you code like that, you're the problem, not JavaScript. Even though it's a valid construct, for compatibility sake, it doesn't mean that modern tools should support or endorse this.

"Oh, but performance...". Yeah, you can also write a perfectly valid code that hurts performance as well. You can even create an infinite loop with valid constructs. It doesn't mean you should.

---

Summarizing what I'm trying to say: your criticism has nothing to do with the language or its evolution pace. They are universal problems around software engineering and will continue to be even if we slowed down.

I've been writing Javascript code since ES3 and my life got significantly better with ES6+.

The existence of TC39 guarantees that a feature will only make it into the language after a very thorough public scrutiny process.

I don't believe we need to go slower. In fact, I wish we could move even faster.


Em dom, 23 de set de 2018 01:32, Henrique Barcelos <[hidden email]> escreveu:
> 1. es6 generators and modules are the top 2 notorious things that come to mind as being difficult to debug/integrate in product-development.

How exactly are generators and modules difficult to integrate or debug? Difficult compared to what?

How are ES modules more complicated for the developer than CommonJS or UMD?

How come generators be more complex than handling a sequence of asynchronous code using a user-land event-based API?

How difficult would it be for Javascript engines to optimize user-land code?

> 2. classes (and typescript, though not directly es6-related), tend to create lots of unnecessary structure that becomes a PITA when you need to rewrite everything, which occurs often in product-development. there are lots of newly minted js-devs entering industry, who lack experience in understanding the risks of javascript over-engineering (and that nothing you write is permanent). they write lots of semi-permanent, es6 infrastructure-code during the initial design-phase, which is a general no-no for many veterans, who understand most of that stuff is going to get tossed out the window and rewritten during integration-phase (and again everytime a ux feature-request comes in that breaks the existing integration-workflow).

What exactly is this related to classes? While I myself am not a fan of the whole classical syntactic sugar on top of prototypal chains, it's not the language's fault that its features are frequently abused and misused.

What you're saying about over-engineering is not intrinsic to the Javascript community, it's a software engineering problem.

Maybe it's because we work in a new field, with roughly 50 years (although programming itself has changed a lot since the 60's). Maybe it's because we're forming bad developers. Maybe it's because software development is a really complex subject.

One thing we can know for sure is that the tools are not the problem. We are. You can use a knife to cook a delicious meal, by you can also use it to kill someone.

> 3. let and const declarations. most code you debug/write in javascript is ux-related integration-code dealing with async-io, which relies heavily on function-scoped closures to pass variables across process-ticks. block-level scoping is an unnecessary design-pattern that leads to confusion over the former.

This is an odd complaint, because variable hoisting was one of the more convoluted features of Javascript, simply because it was different from any other language I've heard of.

I don't think you could even call block-level scoping a "design pattern", because it is a de facto standard for modern languages.

Em sáb, 22 de set de 2018 04:42, kai zhu <[hidden email]> escreveu:
yes, in order of severity:

1. es6 generators and modules are the top 2 notorious things that come to mind as being difficult to debug/integrate in product-development.

2. classes (and typescript, though not directly es6-related), tend to create lots of unnecessary structure that becomes a PITA when you need to rewrite everything, which occurs often in product-development.  there are lots of newly minted js-devs entering industry, who lack experience in understanding the risks of javascript over-engineering (and that nothing you write is permanent).  they write lots of semi-permanent, es6 infrastructure-code during the initial design-phase, which is a general no-no for many veterans, who understand most of that stuff is going to get tossed out the window and rewritten during integration-phase (and again everytime a ux feature-request comes in that breaks the existing integration-workflow).

3. let and const declarations.  most code you debug/write in javascript is ux-related integration-code dealing with async-io, which relies heavily on function-scoped closures to pass variables across process-ticks.  block-level scoping is an unnecessary design-pattern that leads to confusion over the former.

4. fat-arrow.  it has garden-path issues, making it difficult to write efficient javascript-parsers that can differentiate the following [valid] javascript-code:
```js
(aa = 1, bb = 2, cc = 3);
// vs
(aa = 1, bb = 2, cc = 3) => aa + bb;
```
this leads to fundamental performance-issues with tooling/minification/test-coverage-instrumenters.  jslint for efficiency-reasons, simply cheats and assumes both of the above are fat-arrows, and raises fat-arrow warnings for both (and halts further parsing) [1].

[1] jslint managing garden-path complexity of fat-arrow, with a single lookahead, that can turn out wrong, so it halts parsing.


On 22 Sep 2018, at 12:04 PM, Siegfried Bilstein <[hidden email]> wrote:

Do you have examples of the patterns and es6 features you describe? 

Siggy

On Sat, Sep 22, 2018 at 01:02 kai zhu <[hidden email]> wrote:
a problem i've observed in industry is that many es6 language-features have the unintended-consequence of incentivising incompetent javascript-developers at the expense of competent-ones.  its generally difficult for many employers (even those knowledgeable in general-purpose programming), to discern between:

a) a competent javascript employee/contractor who can get things done and ship products (albeit with legitimate delays), and
b) an incompetent-one who can easily hide themselves in non-productive es6 busywork, and continually pushback product-integration (again with “legitimate” delays, until its too late).

its gotten bad enough that many industry-employers no longer trust general-purpose-programming technical-interviews when recruiting js-devs, and rely almost exclusively on either a) an applicant's reputation / word-of-mouth for getting things done, or b) their ability to complete a time-consuming tech-challenge, where they must demonstrate ability to ship a mini-product.  both methods are not scalable to meet the demand in industry for qualified js-devs in product-development.

the only solution i can think of to this industry-problem is to hold-back on introducing new disruptive/unproven javascript design-patterns, and figuring out how to educate the industry with tightened javascript style-guides and existing design-patterns proven to work (more is less); generally, ways to enhance the current, woefully inadequate “bullsh*t detector” of employers so they can better identify and mentor/train/weed-out unqualified js-devs.

--
Job board: http://jobs.nodejs.org/
New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/0BBA242B-D57D-4260-BC24-7983923B43A7%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
Sent from Gmail Mobile

--
Job board: http://jobs.nodejs.org/
New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/CAOd5ZkpWCKLTk9TR%2BeE%2Bg9upuezAf_EQVKnpaOhFNk1SgYiZJA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
--

Henrique

--

Henrique

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [nodejs] Re: javascript vision thing

T.J. Crowder-2
I agree with Isiah. (And like Isiah, I'm just this guy, you know? Not TC39 or anything.)

In particular, the constant re-litigating of decided issues, rehashing the same data-free assertions almost every time anything is suggested to move forward, seems flatly off-topic for the list to me, and I'm a bit surprised that a list admin hasn't dealt with it yet. It's been allowed to go on for far too long. As always, constructive input on something being proposed is great. Constantly banging on that everything since ES5 made life worse is just noise (and would be even if it were true).

-- T.J. Crowder

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
12345