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 <[email protected]> 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 <[email protected]> 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" <[email protected]> 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 <[email protected]> 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 > >> > [email protected] > >> > > >> > 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 <[email protected] > > > >> > 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 <[email protected]> > >> 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" <[email protected]> > 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 < > >> [email protected]> > >> >>> 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 <[email protected]>: > >> >>>>> > >> >>>>> 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 <[email protected]> > >> wrote: > >> >>>>>> > >> >>>>>> How is either operator not "a different way of calling > functions"? > >> >>>>>> > >> >>>>>> On Thu, Feb 22, 2018 at 8:34 PM, Naveen Chawla < > >> [email protected]> > >> >>>>>> 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 > >> >>>>>>> [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 > >> >> > >> >> > >> >> _______________________________________________ > >> >> 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 >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
