Mixing grammars

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

Mixing grammars

Peter van der Zee
I want quickly a point to make. I have a while ago of the, well, I
know actually not how that thing is called, but the "|> operator"
heard. I ignored it as "funny but a very different paradigm than JS".

Now see I today a tweet pass by that somebody a draft of a propasal
has created [1] to this really to JS to add.

I think that it a bad idea is and hope really that the TC39 first a
good research does to the desirability and repercussions of the adding
of similar syntax to the language.

For me is it just like you the Dutch grammar apply on the English.
Like this message tries to show. You.

- peter


1; https://github.com/tc39/proposal-pipeline-operator/issues/52


===

(Dutch)

Ik wil even een punt maken. Ik heb een tijdje geleden van de, tja, ik
weet eigenlijk niet hoe dat ding heet, maar de "|> operator" gehoord.
Ik deed het af als "grappig maar een heel ander paradigma dan JS".

Nou zag ik vandaag een tweet voorbij komen dat iemand een draft van
een proposal heeft opgesteld [1] om dit daadwerkelijk aan JS toe te
voegen.

Ik denk dat het een slecht idee is en hoop echt dat de TC39 eerst een
goed onderzoek doet naar de wenselijkheid en gevolgen van het
toevoegen van dergelijke syntax aan de taal.

Voor mij is het net alsof je de Nederlandse grammatica toepast op het
Engels. Zoals dit bericht probeert aan te tonen.

- peter


1; https://github.com/tc39/proposal-pipeline-operator/issues/52
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Mixing grammars

kdex
Sorry, but your message looks very opinionated and I can't seem to find any
objective reasoning in there. Would you be willing to discuss what exactly you
consider the repercussions to be?

Many functional languages allow function chaining, some even with a similar
syntax. F# features pipe operators as well (in fact, it even features a
literal `|>` operator), and Haskell has `.` and `>>>`.

ECMAScript has many functional parts. So why not offer better support for FP?

On Friday, September 1, 2017 12:54:20 PM CEST Peter van der Zee wrote:

> I want quickly a point to make. I have a while ago of the, well, I
> know actually not how that thing is called, but the "|> operator"
> heard. I ignored it as "funny but a very different paradigm than JS".
>
> Now see I today a tweet pass by that somebody a draft of a propasal
> has created [1] to this really to JS to add.
>
> I think that it a bad idea is and hope really that the TC39 first a
> good research does to the desirability and repercussions of the adding
> of similar syntax to the language.
>
> For me is it just like you the Dutch grammar apply on the English.
> Like this message tries to show. You.
>
> - peter
>
>
> 1; https://github.com/tc39/proposal-pipeline-operator/issues/52
>
>
> ===
>
> (Dutch)
>
> Ik wil even een punt maken. Ik heb een tijdje geleden van de, tja, ik
> weet eigenlijk niet hoe dat ding heet, maar de "|> operator" gehoord.
> Ik deed het af als "grappig maar een heel ander paradigma dan JS".
>
> Nou zag ik vandaag een tweet voorbij komen dat iemand een draft van
> een proposal heeft opgesteld [1] om dit daadwerkelijk aan JS toe te
> voegen.
>
> Ik denk dat het een slecht idee is en hoop echt dat de TC39 eerst een
> goed onderzoek doet naar de wenselijkheid en gevolgen van het
> toevoegen van dergelijke syntax aan de taal.
>
> Voor mij is het net alsof je de Nederlandse grammatica toepast op het
> Engels. Zoals dit bericht probeert aan te tonen.
>
> - peter
>
>
> 1; https://github.com/tc39/proposal-pipeline-operator/issues/52
> _______________________________________________
> 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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Mixing grammars

Peter van der Zee
> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Mixing grammars

kdex
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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Mixing grammars

Naveen Chawla
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):


On Fri, 1 Sep 2017 at 17:36 kdex <[hidden email]> 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
[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: Mixing grammars

kai zhu

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" <[hidden email]> 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):


On Fri, 1 Sep 2017 at 17:36 kdex <[hidden email]> 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
[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: Mixing grammars

Jordan Harband
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 <[hidden email]> 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" <[hidden email]> 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):


On Fri, 1 Sep 2017 at 17:36 kdex <[hidden email]> 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
[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



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

Re: Mixing grammars

kai zhu

> 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" <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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
>>>>[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
>>
>


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

Re: Mixing grammars

Michael Kriegel

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" <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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
>>>>[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
>>
>



_______________________________________________
es-discuss mailing list
[hidden email]
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

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

Re: Mixing grammars

kai zhu

> 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" <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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
>> >>>> [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
>> >>
>> >
>>
>>
>>
>> _______________________________________________ es-discuss mailing list [hidden email] 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
>
>
> _______________________________________________
> 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: Mixing grammars

Jordan Harband
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 <[hidden email]> 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" <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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
>> >>>> [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
>> >>
>> >
>>
>>
>>
>> _______________________________________________ es-discuss mailing list [hidden email] https://mail.mozilla.org/listinfo/es-discuss
>
>
> -- Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 Baar • www.actifsource.com • <a href="tel:+41%2056%20250%2040%2002" value="+41562504002" target="_blank">+41 56 250 40 02
>
>
> _______________________________________________
> 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: Re: Mixing grammars

Jérémy Judéaux
In reply to this post by Peter van der Zee

> 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.

 

I would like to give my opinion about how the `|>` operator solves something new. It’s not the function composition, which is a nice bonus, but mostly already possible with a custom function. It’s function chaining.

 

In the current state of ES, IMO, function chaining is not possible in a maintainable way. I mean without wrapping/unwrapping objects or multilines parentheses blocks, or worse. The `|>` operator (or, if it is abandoned, I’ll put my hopes on the binding operator) allows function chaining.

The benefits I see from function chaining (and so from the `|>` operator):

- Better use of iterables, and probably also streams or observables or promises

- More interoperability of libraries

- More opportunities for developers to solve problems

 

Let me give some examples of what we may see with function chaining:

```js

import _ from 'lodash-for-chaining';
import $ from 'jquery-for-chaining';
import BB from 'bluebird-for-chaining';
import W from 'whenjs-for-chaining';

const toArray = iterable => [...iterable];
new Set([1,2,3,4,5]).entries()
    |> _.filter(x=>x%2)
    |> _.map(x=>x+1)
    |> toArray
    |> console.log;

document.querySelectorAll('a')
    |> $.show
    |> $.css('width', '100%');

// iteroperability
Promise.resolve([1,2,3])
    |> W.spread((a,b,c) => a+b+c)
    |> BB.finally(() => console.log('finally'));

// personnal expectations, give developers the oportunity to solve
// cancellation without waiting another ES feature
fetch(url, {cancelToken: cancellableOperation.token})
    |> cancellableOperation.then(res => res.json())
    |> cancellableOperation.then(res => console.log(res.id));

```

 

And I don’t think these examples are using a very different paradigm than all the ES code written so far, or would be that difficult to apprehend for new developers.



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

Re: Re: Mixing grammars

Mike Samuel
On Thu, Sep 7, 2017 at 10:44 AM, Jérémy Judéaux
<[hidden email]> wrote:

> ```js
>
> import _ from 'lodash-for-chaining';
> import $ from 'jquery-for-chaining';
> import BB from 'bluebird-for-chaining';
> import W from 'whenjs-for-chaining';
>
> const toArray = iterable => [...iterable];
> new Set([1,2,3,4,5]).entries()
>     |> _.filter(x=>x%2)
>     |> _.map(x=>x+1)
>     |> toArray
>     |> console.log;
>
> document.querySelectorAll('a')
>     |> $.show
>     |> $.css('width', '100%');
>
> // iteroperability
> Promise.resolve([1,2,3])
>     |> W.spread((a,b,c) => a+b+c)
>     |> BB.finally(() => console.log('finally'));
>
> // personnal expectations, give developers the oportunity to solve
> // cancellation without waiting another ES feature
> fetch(url, {cancelToken: cancellableOperation.token})
>     |> cancellableOperation.then(res => res.json())
>     |> cancellableOperation.then(res => console.log(res.id));
>
> ```

These are nice examples.  Is there a side-by-side comparison of the
equivalent code without function chaining?
For example, unless I've mistranslated:

new Set([1,2,3,4,5]).entries()
     |> _.filter(x=>x%2)
     |> _.map(x=>x+1)
     |> toArray
     |> console.log;

vs

console.log(
    toArray(
        new Set([1,2,3,4,5]).entries()
           .filter(x=>x%2)
           .map(x=>x+1)));



I ask because I don't understand how pipelining makes operations easier.
The proposal says "and provides a practical alternative to extending
built-in prototypes" which seems like a nice thing to avoid but I'm
not clear on how that happens.

It seems to maybe enable more literate programming.
"We take the widget, bedazzle it, and put it on the fridge"
can be directly translated to
    widget |> bedazzle |> fridge
but
    fridge(bedazzle(widget))
maps to English "The fridge gets a bedazzled widget."
Maybe we should prefer the former since it introduce terms in the
order they're operated upon.
Is that part of the appeal?

I see https://github.com/tc39/proposal-pipeline-operator/wiki/Example-Use-Cases
which has some use cases, but some of those are a stretch, and they
don't seem to relate to avoiding extending built-in prototypes since
the Before code doesn't seem to require extensions.

For example,

"""
Usage with const

// Before
let items = base64ToJSON(response.data.content)
items = Array.isArray(items) ? items : [items]

// After
const items = base64ToJSON(response.data.content)
              |> x => Array.isArray(x) ? x : [x]
"""

shows code that nicely avoids a reassignment, but the unpipelined

    const items = (x => Array.isArray(x) ? x : [x])(
         base64ToJSON(response.data.content))

also avoids reassignment without pipelining.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss