Nobody is wishing away anything with a linter. The linter can only enforce a choice not to use a given language feature.
In any case, I feel this syntax is very valuable, fairly obvious in use, and similar to use in other languages. Pipeline/composition are important features, touched on by several user libraries, none of which are as clean or obvious as the syntax additions proposed. On Wed, Mar 21, 2018, 01:53 Terence M. Bandoian <[email protected]> wrote: > That's very true. However, every new feature is an added cost to the > developer that can't be wished away with a linter. > > -Terence Bandoian > > > On 3/20/2018 6:07 PM, Jordan Harband wrote: > > Learning is a continuing requirement with or without new features in the > language; any one feature *not* added to the language tends to mean you'll > have to learn about more than one userland solution to that problem. > Obviously there's a cost to adding anything to the language - but there's a > cost to *not* adding things too - and in no case are you afforded the > luxury of "no more learning". > > On Tue, Mar 20, 2018 at 12:23 PM, Terence M. Bandoian <[email protected]> > wrote: > >> When "features" are added to the language, developers have to learn >> them. Either that or risk being relegated to second class status. That >> means more time learning about and testing and sorting out support for new >> features and less time actually developing an application. I like the idea >> of "keeping it small". To me, the ideal is a balance of simple and >> powerful. >> >> -Terence Bandoian >> >> >> >> On 3/13/2018 9:59 AM, Mark Miller wrote: >> >> >> >> On Mon, Mar 12, 2018 at 11:33 PM, Jordan Harband <[email protected]> >> wrote: >> >>> 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. >>> >> >> >> Hi Jordan, while I agree with some of your overall point, I think this >> goes way too far. The larger the language, and the more diversity there is >> in which subset one shop chooses vs another, the more we loose the benefits >> of having many developers use a common language. No one shop writes all the >> JS they use. They use libraries written by others whose lint rules are >> different. They hire programmers from other shops. They read and post to >> stackOverflow, etc. >> >> Much better is for the language to omit as much as possible, keeping it >> small. I am glad my "Tragedy of the Common Lisp" post is so widely cited >> and appreciated. Later in that thread, at >> https://esdiscuss.org/topic/the-tragedy-of-the-common-lisp-or-why-large-languages-explode-was-revive-let-blocks#content-22 >> I state a hierarchy of different parts of a language with different >> pressures towards minimality: >> >> >> the force of my [minimality] point gets weaker as we move from core >>> language to standardizing libraries. The overall standard language can be >>> seen as consisting of these major parts: >>> >>> - fundamental syntax -- the special forms that cannot faithfully be >>> explained by local expansion to other syntax >>> >>> >>> - semantic state -- the state than computation manipulates >>> >>> >>> - kernel builtins -- built in library providing functionality that, >>> if it were absent, could not be provided instead by user code. >>> >>> >>> - intrinsics -- libraries that semantic state or kernel builtins >>> depend on. For example, with Proxies, one might be able to do Array in >>> user >>> code. But other kernel builtins already have a dependency on Array >>> specifically, giving it a privileged position over any replacement. >>> >>> >>> - syntactic sugar -- the syntax that can be explained by local >>> expansion to fundamental syntax. >>> >>> >>> - global convenience libraries -- could be implemented by >>> unprivileged user code, but given standard global naming paths in the >>> primordial global namespace. >>> >>> >>> - standard convenient library modules >>> >>> I have listed these in order, according to my sense of the costs of >>> growth and the urgency for minimalism. For all of these we still need to >>> exercise discipline. But it is only for the last one that we should >>> consider growth of absolute size to be unbounded; restricting ourselves >>> only to the rate of growth as we wait for candidates to prove themselves >>> first by the de facto process. Ideally, TC39 should stop being the >>> bottleneck on the last bullet anyway, as external de facto and de jure >>> processes should be perfectly capable of independently arguing about and >>> evolving standard convenience modules. >> >> >> >> Although syntactic sugar is low on the list, it is still costly and best >> avoided when there's no compelling need. "Just use a linter" is not a >> panacea. >> >> >> >>> >>> 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 >>> >>> >> >> >> -- >> Cheers, >> --MarkM >> >> >> >> _______________________________________________ >> 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
