Mixing grammars

Michael Kriegel michael.kriegel at actifsource.com
Wed Sep 6 04:20:16 UTC 2017


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" <ljharb at gmail.com 
> <mailto:ljharb at gmail.com>> 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 <kaizhu256 at gmail.com 
> <mailto:kaizhu256 at gmail.com>> 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" <naveen.chwl at gmail.com 
> <mailto:naveen.chwl at gmail.com>> wrote:
> >>>
> >>> In case anyone is reading this onesdiscuss.org 
> <http://esdiscuss.org>, the 2nd link gets broken when posting it. It's 
> this one (edited onesdiscuss.org <http://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 
> <mailto: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 
> <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 <mailto:es-discuss at mozilla.org>
> >>>>https://mail.mozilla.org/listinfo/es-discuss 
> <https://mail.mozilla.org/listinfo/es-discuss>
> >>>
> >>>
> >>> _______________________________________________
> >>> es-discuss mailing list
> >>>es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> >>>https://mail.mozilla.org/listinfo/es-discuss 
> <https://mail.mozilla.org/listinfo/es-discuss>
> >>>
> >>
> >> _______________________________________________
> >> es-discuss mailing list
> >>es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> >>https://mail.mozilla.org/listinfo/es-discuss 
> <https://mail.mozilla.org/listinfo/es-discuss>
> >>
> >
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170906/07553e34/attachment-0001.html>


More information about the es-discuss mailing list