You can continue using ES5 forever; there's no need to obstruct the progress of the language just because it's evolving to have features you never intend to use.
On Tue, Sep 5, 2017 at 11:06 PM, kai zhu <[email protected]> wrote: > > Kai, I see you often trying to block new inventions with the argument, > that other people will not understand it. > > no insult taken. to me, its a valid argument, and one that i'm not ashamed > to use over and over and over again, nor should anyone else who feels like > me the language-spec is mature, and prefer something with minimal sugar, > like es5 was. > > On Sep 6, 2017 11:20, "Michael Kriegel" <[email protected]> > wrote: > > > > Quoting kai zhu: "more people like me might look at es9/10 code that may > have this feature and think "this looks nothing like javascript" anymore, > and then join es-discuss to complain about having to debug other people's > unreadable code like i do." > > > > Maybe they should read up the manuals / tutorials on the internet > instead? And then if it is still unclear they may ask on stack overflow. I > also stumbled over constructs I did not know in the past, but thats a > normal learning process. E.g. I remember, years ago in the beginning of "my > JS carreer", coming from C, I first stumbled over constructs like this one > (over-simplified, of course): > > > > const X = ((A,B)=>{return A+B;})(A,B); > > > > Well I wasn't aware of unnamed functions being called directly. But I > found out about it. Now I am glad having it. > > > > Kai, I see you often trying to block new inventions with the argument, > that other people will not understand it. But finally it's the decision of > the developer or company guidelines of a company whether to use a feature > or not. And when someone wants to modify someone elses code, he must be > willing to learn whatever constructs the other one found being handy, or, > in case he does not like that, write his own variant which does not use > that construct. And in case the code they try to debug is unreadable for > you, you should consider learning or contact the author and ask him for > clarification or complain there. But after all you are an engineer and a > good engineer does not complain about others just because he does not want > to or is not able to improve his skills. Please don't feel insulted by that > statement. > > > > Example: I personally do not like the syntax (A,B)=>A+B - instead I > prefer writing (A,B)=>{return A+B;}, because it is more explicit and with > the braces I see more easily on where the function body really ends - in > case it is embedded somewhere. So I do not use it. My colleague likes it > and uses it - I do not punish him for that, I just asked him not to use it > when he contributes to my work. We are both fine with that. And I > definitely do not complain on es-discuss about that syntax having been > introduced... > > > > By the way: I probably will not use the pipe syntax suggested in the > referred proposal ATM but I will for sure accept other people doing so and > may also start using it when I see a benefit for my work. > > > > > > On 06.09.2017 01:56, kai zhu wrote: > >> > >> > If operators are in JS, then code using them reads like JS by > definition. > >> > >> we can agree to disagree. more people like me might look at es9/10 > code that may have this feature and think "this looks nothing like > javascript" anymore, and then join es-discuss to complain about having to > debug other people's unreadable code like i do. > >> > >> On Sep 6, 2017 06:40, "Jordan Harband" <[email protected]> wrote: > >> > > >> > If operators are in JS, then code using them reads like JS by > definition. > >> > > >> > On Tue, Sep 5, 2017 at 4:38 PM, kai zhu <[email protected]> wrote: > >> >> > >> >> 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 web-project (which seems to > be happening alot in industry lately), and it reads more like perl than > javascript. > >> >> > >> >> we should be consolidating javascript grammar and design-patterns > instead of fragmenting it further, so that everyone's code can be more > readable to everyone else. > >> >> > >> >> > >> >> On Sep 4, 2017 21:59, "Naveen Chawla" <[email protected]> wrote: > >> >>> > >> >>> In case anyone is reading this on esdiscuss.org, the 2nd link gets > broken when posting it. It's this one (edited on esdiscuss.org): > >> >>> > >> >>> https://github.com/TheNavigateur/proposal-pipeline-operator-for- > function-composition > >> >>> > >> >>> On Fri, 1 Sep 2017 at 17:36 kdex <[email protected]> wrote: > >> >>>> > >> >>>> Ah, I see where you're coming from now. Thanks for the > clarification! > >> >>>> > >> >>>> There has recently been some discussion about the semantics of > `|>` in [1]. > >> >>>> I think what you're looking for is [2], perhaps? > >> >>>> > >> >>>> [1] https://github.com/tc39/proposal-pipeline-operator/issues/50 > >> >>>> [2] https://github.com/TheNavigateur/proposal- > pipeline-operator-for-function-composition > >> >>>> > >> >>>> On Friday, September 1, 2017 1:52:31 PM CEST Peter van der Zee > wrote: > >> >>>> > > Sorry, but your message looks very opinionated and I can't > seem to find > >> >>>> > > any > >> >>>> > > >> >>>> > objective reasoning in there. > >> >>>> > > >> >>>> > Nah, you might be thrown off by the different grammar ;) > >> >>>> > > >> >>>> > Ok. > >> >>>> > > >> >>>> > Thing is, `|>` would introduce a new way of calling a function > in a > >> >>>> > way that is not at all in line with how functions are called in > JS. > >> >>>> > That means JS devs won't easily recognize `a |> b` as easily as > they > >> >>>> > do `b(a)`. (Also consider less text-book-y examples here > please...) > >> >>>> > > >> >>>> > You might argue that this will be a transitional period and I > will > >> >>>> > counter you with an existential question; Why at all? What does > this > >> >>>> > solve? And is it worth the cognitive overhead? > >> >>>> > > >> >>>> > I think this is a bad addition to the language. One that doesn't > "fit" > >> >>>> > with how the language currently works. And one that will lead to > many > >> >>>> > devs being thoroughly confused when confronted with this. > >> >>>> > > >> >>>> > But, I'm not asking you to take my opinion on it. Research it. > Please > >> >>>> > do some research on this. Reach out to devs of all types (not > just > >> >>>> > react devs, not just functional programmers, not just vanilla JS > >> >>>> > coders, not just code golfers, and definitely not just people on > the > >> >>>> > TC39) and figure out how they will respond when confronted with > >> >>>> > additions like this. And please post those results here. I don't > mind > >> >>>> > being wrong. As long as you can back those claims up when > introducing > >> >>>> > something like this. > >> >>>> > > >> >>>> > - peter_______________________________________________ > >> >>>> es-discuss mailing list > >> >>>> [email protected] > >> >>>> https://mail.mozilla.org/listinfo/es-discuss > >> >>> > >> >>> > >> >>> _______________________________________________ > >> >>> es-discuss mailing list > >> >>> [email protected] > >> >>> https://mail.mozilla.org/listinfo/es-discuss > >> >>> > >> >> > >> >> _______________________________________________ > >> >> es-discuss mailing list > >> >> [email protected] > >> >> https://mail.mozilla.org/listinfo/es-discuss > >> >> > >> > > >> > >> > >> > >> _______________________________________________ es-discuss mailing > list [email protected] https://mail.mozilla.org/listinfo/es-discuss > > > > > > -- Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • > CH-6340 Baar • www.actifsource.com • +41 56 250 40 02 > <+41%2056%20250%2040%2002> > > > > > > _______________________________________________ > > es-discuss mailing list > > [email protected] > > https://mail.mozilla.org/listinfo/es-discuss > > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
