All good points :-) I wasn't suggesting there's no cost to adding syntax to a language; I was suggesting that kai's blanket "please don't add new syntax because I don't want to have to deal with it in my project" isn't a useful objection on its own.
On Tue, Mar 13, 2018 at 7:59 AM, Mark Miller <[email protected]> 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-proposa >>>> l#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
