Straw man. The problem is variables named h, f and g, not the use of a
composition operator.

On Sun, 11 Mar 2018 at 07:37, kai zhu <kaizhu...@gmail.com> wrote:

> @peter, put yourself in the shoes of a senior-programmer responsible
> for overseeing an entire web-project.  the project is @ the
> integration-stage and you're busy debugging an async
> timeout/near-timeout bug preventing the frontend from talking to the
> backend (which btw, is one of the most common integration/qa
> javascript-bugs).
>
> while trying to figure out what's causing the timeout-issue, you're
> debugging i/o code with operators that look like this:
>
> ```
> const h = ? |> f |> g;
> ```
>
> maybe it is useful for the small-picture sub-problem you were
> originally trying to solve. but now that you're a bigger-fish with
> bigger-picture integration i/o issues, doesn't this look alot like
> technical-debt that no one will have a clue how to debug once a month
> or two has passed?
>
> -kai
>
> On 3/11/18, Peter Jaszkowiak <p.jasz...@gmail.com> wrote:
> > Oh please,
> >
> > This is an alternative syntax that's very useful for many people. If you
> > want too simplify syntax yourself you can use a linter to disable
> > alternatives.
> >
> > On Mar 10, 2018 22:56, "kai zhu" <kaizhu...@gmail.com> wrote:
> >
> >> my vote is for neither.  exactly what industry painpoint or
> >> problem-space do either of these proposals solve?
> >>
> >> rather, they compound an existing industry painpoint; where
> >> ocd-programmers have problems in deciding-and-choosing which es6
> >> style/design-pattern to employ and stick with before coding even
> >> begins. many of us wish there were less choices, like python (and a
> >> more assertive tc39 that makes clear certain proposals are
> >> productivity-negative and not open for debate) so we could get on with
> >> the actual coding-part.
> >>
> >> from a senior-engineer / technical-manager perspective, it also
> >> doesn't help in managing an entire web-project; comprised of dozens of
> >> sub-components that you didn't all write yourself; and having to
> >> context-switch for each sub-component's quirky es6/es7/es8/es9
> >> style-guide/design-pattern.
> >>
> >> On 3/4/18, Isiah Meadows <isiahmead...@gmail.com> wrote:
> >> > Just thought I'd point out that the proposal itself entertains the
> >> > possibility of a corresponding composition proposal [1]. Also, in my
> >> > proposal, one of my "potential expansions" [2] would open a generic
> >> > door for "lifting" over a type, addressing the concern of
> >> > extensibility. (It's not ideal, and I just filed an issue in my repo
> >> > for that, but that's orthogonal.)
> >> >
> >> > [1]: https://github.com/tc39/proposal-pipeline-operator#
> >> related-proposals
> >> > [2]:
> >> >
> https://github.com/isiahmeadows/function-composition-proposal#possible-
> >> expansions
> >> >
> >> > -----
> >> >
> >> > Isiah Meadows
> >> > m...@isiahmeadows.com
> >> >
> >> > Looking for web consulting? Or a new website?
> >> > Send me an email and we can get started.
> >> > www.isiahmeadows.com
> >> >
> >> >
> >> > On Sat, Feb 24, 2018 at 5:40 AM, Naveen Chawla <naveen.c...@gmail.com
> >
> >> > wrote:
> >> >> Although it doesn't allow composition with generator functions like
> >> >> the
> >> >> composition proposal does, otherwise it's a pretty good solution.
> >> >>
> >> >> My only concern with pipeline is that since it offers a different way
> >> >> of
> >> >> calling functions than the `()` syntax, it can lead to mixed and
> hence
> >> >> slightly more confusing code when both `()` and `|>` are used. For
> >> example
> >> >> multi arg and no-arg functions would still use `()`, and single arg
> >> >> functions may or may not use `|>` depending on whether or not they
> may
> >> >> prospectively use a pipeline. The composition operator doesn't
> >> >> supersede
> >> >> the
> >> >> `()` syntax in any context, and so it could be argued it would lead
> to
> >> >> more
> >> >> consistent, more readable code.
> >> >>
> >> >> On Sat, 24 Feb 2018 at 15:02 Peter Jaszkowiak <p.jasz...@gmail.com>
> >> wrote:
> >> >>>
> >> >>> I'd like to point out the partial application operator:
> >> >>> https://github.com/tc39/proposal-partial-application
> >> >>>
> >> >>> Sounds like the combination of pipeline + partial application would
> >> >>> result
> >> >>> in what is essentially the same as function composition operator:
> >> >>>
> >> >>> ```
> >> >>> const h = ? |> f |> g;
> >> >>> ```
> >> >>>
> >> >>> Which results in `h` being the composition `g • f`.
> >> >>>
> >> >>>
> >> >>> On Feb 24, 2018 02:21, "Naveen Chawla" <naveen.c...@gmail.com>
> wrote:
> >> >>>
> >> >>> That could be a problem for readability.
> >> >>> I agree with the rest of what you said.
> >> >>>
> >> >>>
> >> >>> On Sat, 24 Feb 2018 at 11:16 Viktor Kronvall <
> >> viktor.kronv...@gmail.com>
> >> >>> wrote:
> >> >>>>
> >> >>>> I don’t know the implications but I could easily imagine the
> >> >>>> pipeline
> >> >>>> proposal being extended to not taking any input on the left hand
> >> >>>> side
> >> >>>> and
> >> >>>> effectively represent composition in the opposite direction.
> >> >>>>
> >> >>>> For example:
> >> >>>> ```
> >> >>>> let h = |> f |> g
> >> >>>> h(2) //g(f(2))
> >> >>>> ```
> >> >>>>
> >> >>>> That said, the point holds for the proposal in its current state.
> >> Being
> >> >>>> able to compose functions
> >> >>>> leads to much more expressivity than if you have
> >> >>>> to call the pipeline (and collapse) where it is defined.
> >> >>>> 2018年2月24日(土) 14:32 Naveen Chawla <naveen.c...@gmail.com>:
> >> >>>>>
> >> >>>>> The function composition operator composes function pipelines into
> >> >>>>> functions for later use and/or further composition. Those
> functions
> >> >>>>> still
> >> >>>>> need to be called via the existing `()` syntax, so it doesn't
> offer
> >> >>>>> a
> >> >>>>> different way of calling functions as such.
> >> >>>>>
> >> >>>>> The function pipeline operator calls the function pipeline
> >> immediately,
> >> >>>>> so it is really only a different way of calling functions.
> >> >>>>>
> >> >>>>> On Fri, 23 Feb 2018 at 12:37 Jordan Harband <ljh...@gmail.com>
> >> wrote:
> >> >>>>>>
> >> >>>>>> How is either operator not "a different way of calling
> functions"?
> >> >>>>>>
> >> >>>>>> On Thu, Feb 22, 2018 at 8:34 PM, Naveen Chawla <
> >> naveen.c...@gmail.com>
> >> >>>>>> wrote:
> >> >>>>>>>
> >> >>>>>>> I was just thinking about the relative merits and coexistence
> (or
> >> >>>>>>> not)
> >> >>>>>>> of function composition operator and function pipeline operator
> >> >>>>>>> features:
> >> >>>>>>>
> >> >>>>>>> e.g.
> >> >>>>>>>
> >> >>>>>>>
> https://github.com/TheNavigateur/proposal-pipeline-operator-for-
> >> function-composition
> >> >>>>>>> https://github.com/tc39/proposal-pipeline-operator
> >> >>>>>>>
> >> >>>>>>> They can of course co-exist, but there is overlap only in the
> >> respect
> >> >>>>>>> that both allow function pipelines to be called from left to
> >> >>>>>>> right
> >> >>>>>>> (except
> >> >>>>>>> the input parameter in the case of the composition feature,
> which
> >> >>>>>>> requires
> >> >>>>>>> existing bracket syntax to be used to call it). If one were to
> be
> >> >>>>>>> chosen,
> >> >>>>>>> would say that a function composition operator adds a whole new
> >> >>>>>>> dimension of
> >> >>>>>>> expressive power to the language, whereas a pipeline operator
> >> >>>>>>> only
> >> >>>>>>> offers a
> >> >>>>>>> different way of calling functions.
> >> >>>>>>>
> >> >>>>>>> I was wondering about all of your thoughts about whether you'd
> >> prefer
> >> >>>>>>> only the pipeline operator, only the composition operator, or
> >> >>>>>>> both,
> >> >>>>>>> or
> >> >>>>>>> neither to be added to the language (these are pretty much all
> >> >>>>>>> the
> >> >>>>>>> possibilities), and why.
> >> >>>>>>>
> >> >>>>>>> _______________________________________________
> >> >>>>>>> es-discuss mailing list
> >> >>>>>>> es-discuss@mozilla.org
> >> >>>>>>> https://mail.mozilla.org/listinfo/es-discuss
> >> >>>>>>>
> >> >>>>>>
> >> >>>>> _______________________________________________
> >> >>>>> es-discuss mailing list
> >> >>>>> es-discuss@mozilla.org
> >> >>>>> https://mail.mozilla.org/listinfo/es-discuss
> >> >>>
> >> >>>
> >> >>> _______________________________________________
> >> >>> es-discuss mailing list
> >> >>> es-discuss@mozilla.org
> >> >>> https://mail.mozilla.org/listinfo/es-discuss
> >> >>>
> >> >>>
> >> >>> _______________________________________________
> >> >>> es-discuss mailing list
> >> >>> es-discuss@mozilla.org
> >> >>> https://mail.mozilla.org/listinfo/es-discuss
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> es-discuss mailing list
> >> >> es-discuss@mozilla.org
> >> >> https://mail.mozilla.org/listinfo/es-discuss
> >> >>
> >> > _______________________________________________
> >> > es-discuss mailing list
> >> > es-discuss@mozilla.org
> >> > https://mail.mozilla.org/listinfo/es-discuss
> >> >
> >> _______________________________________________
> >> es-discuss mailing list
> >> es-discuss@mozilla.org
> >> https://mail.mozilla.org/listinfo/es-discuss
> >>
> >
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to