3 ms·

> once you move away from toy examples, most pipeline operator use cases are already covered by chaining class methods on classes But what if we don't want to

> once you move away from toy examples, most pipeline operator use cases are already covered by chaining class methods on classes But what if we don't want to use classes? What if we want to be cool and compose functions out of functions, Ramda-style, or Elm-style?

nsonha 5y ago
Unpopular opinion: we could just add, say, `pipe` and `pipeAsync` into the standard library, appart from aesthetic, I don't see the pipe operator to be very useful, at least the F# one doesn't because it's literally just another syntax for function invocation.
- azangru 5y ago
  Standard library? In javascript? You mean a keyword like `async` or `yield`, or a built-in object like Date or Math?
- pygy_ 5y ago
  When you look at a Ramda-based JS code base, all there is to look at is function calls. Such code eschews most statements. Piping is a common operation, though, and having dedicated syntax makes the code more readable. For those code bases that use curried, unary functions, the F# proposal is perfect (this is the original motivation behind the operator). The hack-style pipe syntax that has been chosen is much worse in that regard, which is disappointing for the very folks that requested its addition.
- slaymaker1907 5y ago
  It is useful as an operator due to the fact that you avoid unnecessary function calls/lambda creation. "pipe(x, f, g, y => h(42, y))" is not going to be as easy to optimize as "h(42, g(f(x))" yet "x |> f |> g |> h(42, ^)" has the ordering of the pipe function while being equivalent to normal function invocation for the purposes of optimization. I sort of agree though about the F# proposal version. It doesn't make sense to introduce if it is basically equivalent to having a pipe/pipeAsync function. I suspect this is a big reason why the Hack version was favored.

3 ms·

> once you move away from toy examples, most pipeline operator use cases are already covered by chaining class methods on classes But what if we don't want to

by azangru 5y ago

nsonha 5y ago
Unpopular opinion: we could just add, say, `pipe` and `pipeAsync` into the standard library, appart from aesthetic, I don't see the pipe operator to be very useful, at least the F# one doesn't because it's literally just another syntax for function invocation.
- azangru 5y ago
  Standard library? In javascript? You mean a keyword like `async` or `yield`, or a built-in object like Date or Math?
- pygy_ 5y ago
  When you look at a Ramda-based JS code base, all there is to look at is function calls. Such code eschews most statements. Piping is a common operation, though, and having dedicated syntax makes the code more readable. For those code bases that use curried, unary functions, the F# proposal is perfect (this is the original motivation behind the operator). The hack-style pipe syntax that has been chosen is much worse in that regard, which is disappointing for the very folks that requested its addition.
- slaymaker1907 5y ago
  It is useful as an operator due to the fact that you avoid unnecessary function calls/lambda creation. "pipe(x, f, g, y => h(42, y))" is not going to be as easy to optimize as "h(42, g(f(x))" yet "x |> f |> g |> h(42, ^)" has the ordering of the pipe function while being equivalent to normal function invocation for the purposes of optimization. I sort of agree though about the F# proposal version. It doesn't make sense to introduce if it is basically equivalent to having a pipe/pipeAsync function. I suspect this is a big reason why the Hack version was favored.