Mixing grammars

kai zhu kaizhu256 at gmail.com
Tue Sep 5 23:38:51 UTC 2017


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" <naveen.chwl at gmail.com> 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 <kdex at kdex.de> 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
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170906/55422690/attachment.html>


More information about the es-discuss mailing list