ES Discuss - Message History

Bob Myers (2018-03-23T03:02:27.000Z)

Go to Source

>  The point is that there is an unavoidable cost to the developer when
features are added to the language.  My apologies if that wasn't clear.

You don't really need to argue that there is an unavoidable cost to new
features. Few would disagree. And this cost is already taken into account
in discussions of new features.

Your argument seems to actually be that such cost should be weighted more
heavily.

Opinions will differ on that point, of course, but I would say that people
arguing for a heavy weighting of language complexity costs are
underestimating the audience (as well as often overestimating those costs).
Developers are people who have learned new languages, frameworks, and
libraries their entire lives, and are probably learning new features in
their existing stack as I write this. They ENJOY that. That's part of the
job description. If you actually want to freeze time and stop the evolution
of technology, of course, you'd have to not only stop new JS developments,
but also new Web API and/or CSS features, since hey, those also can confuse
people! If I am a manager, and my developers are incapable or unwilling to
learn how to use these evolutionary improvements in technology, then I
should replace them, or maybe I myself can find a new job at a company
which is still writing some good old ASP+jQuery pages..

Bob


On Fri, Mar 23, 2018 at 7:14 AM, Terence M. Bandoian <terence at tmbsw.com>
wrote:

> The point is that there is an unavoidable cost to the developer when
> features are added to the language.  My apologies if that wasn't clear.
>
> -Terence Bandoian
>
>
> On 3/22/2018 11:20 AM, Michael J. Ryan wrote:
>
> 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 <terence at tmbsw.com> 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 <terence at tmbsw.com>
>> 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 <ljharb at 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 <terence at 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" <kaizhu256 at 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.jaszkow at 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" <kaizhu256 at 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 <isiahmeadows at 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-proposal#possible-
>>>>>> >> expansions
>>>>>> >> >
>>>>>> >> > -----
>>>>>> >> >
>>>>>> >> > Isiah Meadows
>>>>>> >> > me at 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.chwl at 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.jaszkow at 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.chwl at 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.kronvall at 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.chwl at 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 <
>>>>>> ljharb at 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.chwl at 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 at mozilla.org
>>>>>> >> >>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>> >> >>>>>>>
>>>>>> >> >>>>>>
>>>>>> >> >>>>> _______________________________________________
>>>>>> >> >>>>> es-discuss mailing list
>>>>>> >> >>>>> es-discuss at mozilla.org
>>>>>> >> >>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>> >> >>>
>>>>>> >> >>>
>>>>>> >> >>> _______________________________________________
>>>>>> >> >>> es-discuss mailing list
>>>>>> >> >>> es-discuss at mozilla.org
>>>>>> >> >>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>> >> >>>
>>>>>> >> >>>
>>>>>> >> >>> _______________________________________________
>>>>>> >> >>> es-discuss mailing list
>>>>>> >> >>> es-discuss at mozilla.org
>>>>>> >> >>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>> >> >>
>>>>>> >> >>
>>>>>> >> >> _______________________________________________
>>>>>> >> >> es-discuss mailing list
>>>>>> >> >> es-discuss at mozilla.org
>>>>>> >> >> https://mail.mozilla.org/listinfo/es-discuss
>>>>>> >> >>
>>>>>> >> > _______________________________________________
>>>>>> >> > es-discuss mailing list
>>>>>> >> > es-discuss at mozilla.org
>>>>>> >> > https://mail.mozilla.org/listinfo/es-discuss
>>>>>> >> >
>>>>>> >> _______________________________________________
>>>>>> >> es-discuss mailing list
>>>>>> >> es-discuss at mozilla.org
>>>>>> >> https://mail.mozilla.org/listinfo/es-discuss
>>>>>> >>
>>>>>> >
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> es-discuss mailing list
>>>>> es-discuss at mozilla.org
>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss at mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>>
>>>
>>>
>>> --
>>>   Cheers,
>>>   --MarkM
>>>
>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180323/c5b2a8ca/attachment-0001.html>

rtm at gol.com (2018-03-23T06:27:15.011Z)

>  The point is that there is an unavoidable cost to the developer when features are added to the language.  My apologies if that wasn't clear.

You don't really need to argue that there is an unavoidable cost to new
features. Few would disagree. And this cost is already taken into account
in discussions of new features.

Your argument seems to actually be that such cost should be weighted more
heavily.

Opinions will differ on that point, of course, but I would say that people
arguing for a heavy weighting of language complexity costs are
underestimating the audience (as well as often overestimating those costs).
Developers are people who have learned new languages, frameworks, and
libraries their entire lives, and are probably learning new features in
their existing stack as I write this. They ENJOY that. That's part of the
job description. If you actually want to freeze time and stop the evolution
of technology, of course, you'd have to not only stop new JS developments,
but also new Web API and/or CSS features, since hey, those also can confuse
people! If I am a manager, and my developers are incapable or unwilling to
learn how to use these evolutionary improvements in technology, then I
should replace them, or maybe I myself can find a new job at a company
which is still writing some good old ASP+jQuery pages..

Bob

Edit