As someone who does wear the shoes of a senior programmer responsible (along with my team) for overseeing a very very large web project, the super trivial and easy answer to this is "use a linter" - eslint can be configured to restrict any syntax you like, and since surely your CI process is already gating any merges, so too can the linter be used to gate merges, which will prevent anyone from any using any syntax you deem unclean.
Tons of new syntax can be added to JavaScript forever and it need not have a single bit of impact on any of your project's code except a few lines in your eslint configuration. On Mon, Mar 12, 2018 at 8:26 AM, Terence M. Bandoian <[email protected]> wrote: > In my opinion, one of the more significant advances in the C programming > language was the increase in the maximum length of identifiers. To me, > this translates to "less cryptic is better". > > -Terence Bandoian > > > > On 3/11/2018 1:09 AM, Peter Jaszkowiak wrote: > > Personally, I'd push my subordinates to learn this new syntax. But if you > dislike it, you can blacklist it in your linter: it's one of the main > features of a linter. > > On Mar 10, 2018 23: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
