@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
