Re: Function composition vs pipeline

[Bob Myers]

>  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 
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  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 
>> 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 
>>> 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 [minimalit

Re: Function composition vs pipeline

[Terence M. Bandoian]

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 > 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
mailto:tere...@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
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
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

Re: Re: Function composition vs pipeline

[Michael J. Ryan]

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  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 
> 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 
>> 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

Re: Re: Function composition vs pipeline

[Terence M. Bandoian]

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 
mailto:tere...@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
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


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 syntac

Re: Function composition vs pipeline

[Jordan Harband]

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 
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  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 
>> 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

Re: Function composition vs pipeline

[Terence M. Bandoian]

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 > 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
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" 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 p

Re: Function composition vs pipeline

[Scott Sauyet]

I would probably structure this so differently that it's hard to even say
where the changes should be.  I don't know the Electron API, so the
following is almost certainly wrong, but it should demonstrate the basic
ideas:


```
const promisify = require('some-promisify-function');
const BrowserWindow = require('electron').BrowserWindow;
const options = { frame: false, height: 768, width: 1024, x: 0, y: 0 };

const delay = time => value => new Promise(resolve =>
  setTimeout(() => resolve(value), time)
)

const loadElectron = () => {
  console.log('wait for electron to init');
  return promisify(require('electron').app.once)('ready');
}

const open = () => {
  const url = process.argv[2];
  console.log(`open url ${url}`);
  window = new BrowserWindow(options);
  window.loadURL(url);
  return promisify(window.webContents.once)('did-stop-loading')
.then(() => window);
}

const capture = window => {
  console.log('screenshot webpage');
  return promisify(window.capturePage)(options);
}

const save = screenshot => {
  console.log('save file electron.screenshot.png');
  return promisify(require('fs').writeFile)('electron.screenshot.png',
data.toPng())
}

const exit = () => {
  console.log('exit electron');
  process.exit(0);
}

loadElectron()
  .then(open)
  .then(delay(5000))
  .then(capture)
  .then(save)
  .then(exit)
```

And with one of the pipeline proposals, the final bit would look something
like this:

```
await loadElectron()
  |> await open
  |> await delay(5000)
  |> await capture
  |> await save
  |> exit
```

I have no ideas if we could find one `promisify` function that could handle
the various parts of the Electron API, but we could certainly manage this
with individual wrappers if necessary.

I personally find this style *much* more readable.

I consider myself a senior-level developer, and I use Ramda's `pipe` and
`compose` [1] all the time.  While I don't have particularly strong
feelings on the pipeline proposals, suggesting that they are only for toy
problems seems absurd to me.


  [1]: http://ramdajs.com/docs/?pipe, http://ramdajs.com/docs/?compose


  -- Scott


> On Mar 15, 2018, at 10:49 PM, Michael J. Ryan  wrote:
>
> And only 50x the amount of code too.
>
>
> fair enough.  but lets move from small-picture toy-cases to bigger-picture
> integration-level ones, where non-blocking code is common.
>
> here's a working, simple but useful 40-sloc real-world electron-script [1]
> which employs a single recursive-callback (function onNext()) to
> step-by-step screen-capture websites/demos to png.  how would you
> re-express the linear-steps in the example into something significantly
> more readable with function-composition or pipeline-operators?
>
> ```
> /*
>  * screen-capture.js
>  *
>  * this electron-script will screen-capture the website with the given url
> in the commandline
>  *
>  * exsmple usage:
>  *$ electron screen-capture.js https://www.pinterest.com/
>  *
>  * output:
>  *case 1: wait for electron to init
>  *case 2: open url https://www.pinterest.com/
>  *case 3: wait 5000ms for webpage to render
>  *case 4: screenshot webpage
>  *case 5: save file electron.screenshot.png
>  *case 6: exit electron
>  */
>
> /*jslint
> bitwise: true,
> browser: true,
> maxerr: 8,
> maxlen: 96,
> node: true,
> nomen: true,
> regexp: true,
> stupid: true
> */
> (function () {
> 'use strict';
> var options, modeNext, onNext;
> modeNext = 0;
> onNext = function (data) {
> modeNext += 1;
> switch (modeNext) {
> case 1:
> console.log('case ' + modeNext + ': wait for electron to
> init');
> // wait for electron to init
> require('electron').app.once('ready', onNext);
> break;
> case 2:
> console.log('case ' + modeNext + ': open url ' +
> process.argv[2]);
> // init options
> options = { frame: false, height: 768, width: 1024, x: 0, y: 0
> };
> // init browserWindow;
> options.BrowserWindow = require('electron').BrowserWindow;
> options.browserWindow = new options.BrowserWindow(options);
> // goto next step when webpage is loaded
> options.browserWindow.webContents.once('did-stop-loading',
> onNext);
> // open url
> options.browserWindow.loadURL(process.argv[2]);
> break;
> case 3:
> console.log('case ' + modeNext + ': wait 5000ms for webpage to
> render’);
> // wait 5000ms for webpage to render
> setTimeout(onNext, 5000);
> break;
> case 4:
> console.log('case ' + modeNext + ': screenshot webpage');
> // screenshot webpage
> options.browserWindow.capturePage(options, onNext);
> break;
> case 5:
> console.log('case ' + modeNext + ': save file
> electron.screenshot.png');
> 

Re: Function composition vs pipeline

[kai zhu]

@michael, integration-level javascript rarely deals with blocking-code.  its 
mostly tedious-work debugging and “fixing” endless piles of async-io timeout 
issues, without the help of a stack-trace :`(  and the term “fixing” is 
oftentimes euphemism for “rewriting the carefully architected backend into 
something simpler-and-dumber, because it turns out to have too many timeout 
issues during integration”.

you can’t seriously call yourself a senior-developer if you insist on using 
irrelevant blocking-code design-patterns like function-composition or 
pipeline-operators at such a level, which mostly gets in the way of your 
debugging and “fixing" tasks.  and using these features at the lower 
library-level only reinforce blocking-code-mindset bad-habits that will set you 
up for failure, when you're promoted to take on integration-level 
responsibilities.

btw, 2 of the async-steps in the example provided requires listening to 
triggered-events to proceed.  subjectively, the stack-overflow workaround i 
found for async/await to handle events [1] looks a bit more hacky and less 
clean than my example:

```
async function fn() {
  await a();
  await b();
  const [{data}, cResult] = await Promise.all([
new Promise(resolve => thing.once('myEvent', resolve)),
c()
  ]);
  return data;
}
```

but if you think you can create cleaner-code than what i posted using 
async/await, then feel free to try.

-kai

[1] 
https://stackoverflow.com/questions/43084557/using-promises-to-await-triggered-events
 


> On Mar 16, 2018, at 8:35 AM, Michael J. Ryan  wrote:
> 
> Does the existence of a pipeline operator stop such code from working?
> 
> Frankly, I'd probably structure your example more as an async function...
> 
> -- 
> Michael J. Ryan - http://tracker1.info 
> 
> On Thu, Mar 15, 2018 at 9:22 AM, kai zhu  > wrote:
> 
>> On Mar 15, 2018, at 10:49 PM, Michael J. Ryan > > wrote:
>> 
>> And only 50x the amount of code too.
>> 
> 
> fair enough.  but lets move from small-picture toy-cases to bigger-picture 
> integration-level ones, where non-blocking code is common.
> 
> here's a working, simple but useful 40-sloc real-world electron-script [1] 
> which employs a single recursive-callback (function onNext()) to step-by-step 
> screen-capture websites/demos to png.  how would you re-express the 
> linear-steps in the example into something significantly more readable with 
> function-composition or pipeline-operators?
> 
> ```
> /*
>  * screen-capture.js
>  *
>  * this electron-script will screen-capture the website with the given url in 
> the commandline
>  *
>  * exsmple usage:
>  *$ electron screen-capture.js https://www.pinterest.com/ 
> 
>  *
>  * output:
>  *case 1: wait for electron to init
>  *case 2: open url https://www.pinterest.com/ 
>  *case 3: wait 5000ms for webpage to render
>  *case 4: screenshot webpage
>  *case 5: save file electron.screenshot.png
>  *case 6: exit electron
>  */
> 
> /*jslint
> bitwise: true,
> browser: true,
> maxerr: 8,
> maxlen: 96,
> node: true,
> nomen: true,
> regexp: true,
> stupid: true
> */
> (function () {
> 'use strict';
> var options, modeNext, onNext;
> modeNext = 0;
> onNext = function (data) {
> modeNext += 1;
> switch (modeNext) {
> case 1:
> console.log('case ' + modeNext + ': wait for electron to init');
> // wait for electron to init
> require('electron').app.once('ready', onNext);
> break;
> case 2:
> console.log('case ' + modeNext + ': open url ' + process.argv[2]);
> // init options
> options = { frame: false, height: 768, width: 1024, x: 0, y: 0 };
> // init browserWindow;
> options.BrowserWindow = require('electron').BrowserWindow;
> options.browserWindow = new options.BrowserWindow(options);
> // goto next step when webpage is loaded
> options.browserWindow.webContents.once('did-stop-loading', 
> onNext);
> // open url
> options.browserWindow.loadURL(process.argv[2]);
> break;
> case 3:
> console.log('case ' + modeNext + ': wait 5000ms for webpage to 
> render’);
> // wait 5000ms for webpage to render
> setTimeout(onNext, 5000);
> break;
> case 4:
> console.log('case ' + modeNext + ': screenshot webpage');
> // screenshot webpage
> options.browserWindow.capturePage(options, onNext);
> break;
> case 5:
> console.log('case ' + modeNext + ': save file 
> electron.screenshot.png');
> // save screenshot
> r

Re: Function composition vs pipeline

[Alexander Jones]

Straw man. The problem is variables named h, f and g, not the use of a
composition operator.

On Sun, 11 Mar 2018 at 07:37, kai zhu  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  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"  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  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
> >> > 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  >
> >> > 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 
> >> 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" 
> 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 direc

Re: Function composition vs pipeline

[Jordan Harband]

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  wrote:

>
>
> On Mon, Mar 12, 2018 at 11:33 PM, Jordan Harband  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 
>> 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"  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

Re: Function composition vs pipeline

[Mark Miller]

On Mon, Mar 12, 2018 at 11:33 PM, Jordan Harband  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 
> 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"  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  wrote:
>>> > Oh

Re: Function composition vs pipeline

[Jordan Harband]

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.

On Mon, Mar 12, 2018 at 8:26 AM, Terence M. Bandoian 
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"  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  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"  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  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
>> >> > 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
>>

Re: Function composition vs pipeline

[Terence M. Bandoian]

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" > 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 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" 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 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#

>> related-proposals
>> > [2]:
>> >
https://github.com/isiahmeadows/function-composition-proposal#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
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
mailto:p.jasz...@gmail.com>>
>> wrote:
>> >>>
>> >>> I'd like to point out the partial application operator:
>> >>

Re: Function composition vs pipeline

[Peter Jaszkowiak]

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"  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  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"  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  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
> >> > 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  >
> >> > 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 
> >> 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" 
> 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
> >>  

Re: Function composition vs pipeline

[kai zhu]

@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  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"  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  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
>> > 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 
>> > 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 
>> 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"  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 :

Re: Function composition vs pipeline

[Peter Jaszkowiak]

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"  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  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
> > 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 
> > 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 
> 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"  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 :
> >
> > 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 
> 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.
> >>>
> >>> h

Re: Function composition vs pipeline

[kai zhu]

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  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
> 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 
> 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  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"  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 
>>> 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 :
>
> 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  wrote:
>>
>> How is either operator not "a different way of calling functions"?
>>
>> On Thu, Feb 22, 2018 at 8:34 PM, Naveen Chawla 
>> 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 

Re: Function composition vs pipeline

[Isiah Meadows]

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
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  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  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"  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 
>> 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 :

 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  wrote:
>
> How is either operator not "a different way of calling functions"?
>
> On Thu, Feb 22, 2018 at 8:34 PM, Naveen Chawla 
> 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
>>
>>
>> _

Re: Function composition vs pipeline

[Naveen Chawla]

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  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"  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 
> 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 :
>>
>>> 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  wrote:
>>>
 How is either operator not "a different way of calling functions"?

 On Thu, Feb 22, 2018 at 8:34 PM, Naveen Chawla 
 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

Re: Function composition vs pipeline

[Peter Jaszkowiak]

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"  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 
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 :
>
>> 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  wrote:
>>
>>> How is either operator not "a different way of calling functions"?
>>>
>>> On Thu, Feb 22, 2018 at 8:34 PM, Naveen Chawla 
>>> 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

Re: Function composition vs pipeline

[Naveen Chawla]

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 
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 :
>
>> 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  wrote:
>>
>>> How is either operator not "a different way of calling functions"?
>>>
>>> On Thu, Feb 22, 2018 at 8:34 PM, Naveen Chawla 
>>> 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

Re: Function composition vs pipeline

[Viktor Kronvall]

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 :

> 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  wrote:
>
>> How is either operator not "a different way of calling functions"?
>>
>> On Thu, Feb 22, 2018 at 8:34 PM, Naveen Chawla 
>> 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

Re: Function composition vs pipeline

[Naveen Chawla]

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  wrote:

> How is either operator not "a different way of calling functions"?
>
> On Thu, Feb 22, 2018 at 8:34 PM, Naveen Chawla 
> 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

Re: Re: Function composition vs pipeline

[J. S. Choi]

See also recent discussions in these GitHub issues that touch on composition: 
https://github.com/tc39/proposal-pipeline-operator/issues?q=composition+sort%3Aupdated-desc.

Look particularly at the issues that were created after 2018-01-31 – when 
Gilbert/Mindeavor split the proposal into four competing proposals – since 
those issues reflect the current state of the art. To see those four competing 
proposals, look at the pipeline operator’s wiki, which has a list of the four 
proposals (https://github.com/tc39/proposal-pipeline-operator/wiki).

In particular, Naveem, you may be interested in 
https://github.com/tc39/proposal-pipeline-operator/issues/93, which discusses 
the intersection of terse function application and terse function composition.___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Function composition vs pipeline

[Jordan Harband]

How is either operator not "a different way of calling functions"?

On Thu, Feb 22, 2018 at 8:34 PM, Naveen Chawla 
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