On Mon, Mar 12, 2018 at 11:33 PM, Jordan Harband
<ljh...@gmail.com <mailto: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
<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 <mailto: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
<mailto: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
<mailto: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 <mailto: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
<mailto: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#
<https://github.com/tc39/proposal-pipeline-operator#>
>> related-proposals
>> > [2]:
>> >
https://github.com/isiahmeadows/function-composition-proposal#possible-
<https://github.com/isiahmeadows/function-composition-proposal#possible->
>> expansions
>> >
>> > -----
>> >
>> > Isiah Meadows
>> > m...@isiahmeadows.com <mailto:m...@isiahmeadows.com>
>> >
>> > Looking for web consulting? Or a new website?
>> > Send me an email and we can get started.
>> > www.isiahmeadows.com <http://www.isiahmeadows.com>
>> >
>> >
>> > On Sat, Feb 24, 2018 at 5:40 AM, Naveen Chawla
<naveen.c...@gmail.com <mailto: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 <mailto:p.jasz...@gmail.com>>
>> wrote:
>> >>>
>> >>> I'd like to point out the partial application
operator:
>> >>>
https://github.com/tc39/proposal-partial-application
<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
<mailto: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
<mailto: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 <mailto: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 <mailto: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 <mailto: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-
<https://github.com/TheNavigateur/proposal-pipeline-operator-for->
>> function-composition
>> >>>>>>>
https://github.com/tc39/proposal-pipeline-operator
<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
<mailto:es-discuss@mozilla.org>
>> >>>>>>>
https://mail.mozilla.org/listinfo/es-discuss
<https://mail.mozilla.org/listinfo/es-discuss>
>> >>>>>>>
>> >>>>>>
>> >>>>> _______________________________________________
>> >>>>> es-discuss mailing list
>> >>>>> es-discuss@mozilla.org
<mailto:es-discuss@mozilla.org>
>> >>>>>
https://mail.mozilla.org/listinfo/es-discuss
<https://mail.mozilla.org/listinfo/es-discuss>
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> es-discuss mailing list
>> >>> es-discuss@mozilla.org
<mailto:es-discuss@mozilla.org>
>> >>> https://mail.mozilla.org/listinfo/es-discuss
<https://mail.mozilla.org/listinfo/es-discuss>
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> es-discuss mailing list
>> >>> es-discuss@mozilla.org
<mailto:es-discuss@mozilla.org>
>> >>> https://mail.mozilla.org/listinfo/es-discuss
<https://mail.mozilla.org/listinfo/es-discuss>
>> >>
>> >>
>> >> _______________________________________________
>> >> es-discuss mailing list
>> >> es-discuss@mozilla.org
<mailto:es-discuss@mozilla.org>
>> >> https://mail.mozilla.org/listinfo/es-discuss
<https://mail.mozilla.org/listinfo/es-discuss>
>> >>
>> > _______________________________________________
>> > es-discuss mailing list
>> > es-discuss@mozilla.org
<mailto:es-discuss@mozilla.org>
>> > https://mail.mozilla.org/listinfo/es-discuss
<https://mail.mozilla.org/listinfo/es-discuss>
>> >
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss@mozilla.org
<mailto:es-discuss@mozilla.org>
>> https://mail.mozilla.org/listinfo/es-discuss
<https://mail.mozilla.org/listinfo/es-discuss>
>>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>
https://mail.mozilla.org/listinfo/es-discuss
<https://mail.mozilla.org/listinfo/es-discuss>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>
https://mail.mozilla.org/listinfo/es-discuss
<https://mail.mozilla.org/listinfo/es-discuss>
--
Cheers,
--MarkM
