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 <erig...@gmail.com> wrote:

>
>
> On Mon, Mar 12, 2018 at 11:33 PM, Jordan Harband <ljh...@gmail.com> 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 <tere...@tmbsw.com>
>> 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" <kaizhu...@gmail.com> 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 <p.jasz...@gmail.com> 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" <kaizhu...@gmail.com> 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 <isiahmead...@gmail.com> 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
>>>> >> > m...@isiahmeadows.com
>>>> >> >
>>>> >> > 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 <
>>>> naveen.c...@gmail.com>
>>>> >> > 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 <
>>>> p.jasz...@gmail.com>
>>>> >> 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" <naveen.c...@gmail.com>
>>>> 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 <
>>>> >> viktor.kronv...@gmail.com>
>>>> >> >>> 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 <naveen.c...@gmail.com>:
>>>> >> >>>>>
>>>> >> >>>>> 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 <ljh...@gmail.com>
>>>> >> wrote:
>>>> >> >>>>>>
>>>> >> >>>>>> How is either operator not "a different way of calling
>>>> functions"?
>>>> >> >>>>>>
>>>> >> >>>>>> On Thu, Feb 22, 2018 at 8:34 PM, Naveen Chawla <
>>>> >> naveen.c...@gmail.com>
>>>> >> >>>>>> 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
>>>> >> >>>>>>> es-discuss@mozilla.org
>>>> >> >>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>> >> >>>>>>>
>>>> >> >>>>>>
>>>> >> >>>>> _______________________________________________
>>>> >> >>>>> es-discuss mailing list
>>>> >> >>>>> es-discuss@mozilla.org
>>>> >> >>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>> >> >>>
>>>> >> >>>
>>>> >> >>> _______________________________________________
>>>> >> >>> es-discuss mailing list
>>>> >> >>> es-discuss@mozilla.org
>>>> >> >>> https://mail.mozilla.org/listinfo/es-discuss
>>>> >> >>>
>>>> >> >>>
>>>> >> >>> _______________________________________________
>>>> >> >>> es-discuss mailing list
>>>> >> >>> es-discuss@mozilla.org
>>>> >> >>> https://mail.mozilla.org/listinfo/es-discuss
>>>> >> >>
>>>> >> >>
>>>> >> >> _______________________________________________
>>>> >> >> es-discuss mailing list
>>>> >> >> es-discuss@mozilla.org
>>>> >> >> https://mail.mozilla.org/listinfo/es-discuss
>>>> >> >>
>>>> >> > _______________________________________________
>>>> >> > es-discuss mailing list
>>>> >> > es-discuss@mozilla.org
>>>> >> > https://mail.mozilla.org/listinfo/es-discuss
>>>> >> >
>>>> >> _______________________________________________
>>>> >> es-discuss mailing list
>>>> >> es-discuss@mozilla.org
>>>> >> https://mail.mozilla.org/listinfo/es-discuss
>>>> >>
>>>> >
>>>>
>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> --
>   Cheers,
>   --MarkM
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to