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
