proposal-pipeline-operator

Please have someone on your team take a good hard look at the current proposal-pipeline-operator: https://github.com/tc39/proposal-pipeline-operator It started as a Function Composition proposal (using the pipe operator |>) but after a change of leadership it has turned into something much different. We might need another perspective on the current trajectory of this proposal, as in its current form it seems to many in the community it might take JS in the wrong direction. Thanks!

OP's link provides answers[1] to that question. And in my personal view, they aren't very convincing. The first answer, tedium, is unconvincing, because pretty much anyone with more than a couple of years of experience in software development in a team knows that ease of reading beats ease of writing. The second answer, unexpected mutation of temporary variables, seems to point to a deeper issue in JavaScript. That of const not quite being const. Unless you Object.freeze everything. The third answer, that temporary variables require sequences of statements instead of a single big expression, is more of a feature than a bug, in my personal opinion. Statements allow the reader to comprehend the algorithm one step at a time instead of trying to untangle one giant expression. To say nothing about the fact that a sequence of statements is

Does anybody more involved in this topic know how high the chance of this getting implemented is? It mentions that this has been rejected twice before, mainly for runtime optimization reasons, and that there is another proposal [1] that mentions this as an extension to its functionality. 1: https://github.com/tc39/proposal-pipeline-operator

I have strong doubts that partial application will ever advance from stage 1. The reason is that partial application was supposed to compliment the pipeline operator[1]. value |> fn(?, "static string") However earlier this month they advanced a version of the pipeline operator with a definite topic marker which makes partial application useless in the RHS of the pipeline operator. This was of course really controversial, as you can see if you read thought the most resent issues (particularly the closed ones). https://github.com/tc39/proposal-pipeline-operator

We were hoping for similar operators in JavaScript (pipeline `|>` and partial application `?`). However TC39 just decided earlier this month that we users of the language are not worthy of such powers. This was off course meet with a lot of resentment from many JavaScript developers, including my self. https://github.com/tc39/proposal-pipeline-operator

There’s a lot of bikeschedding on how to use it in conjunction with the (also stage 1 proposal and forever delayed) pipeline operator[1] unfortunately. Add in never ending arguments on which symbol we should use (the questionmark has a lot of responsibilities already) and here we are. To make matters worse it appear that generally OOP style darlings such as static class blocks and true private fields seem to gain more momentum. [1] https://github.com/tc39/proposal-pipeline-operator/wiki

The most common case I’ve seen is when you want to map using 'point free' style functions, i.e. “x.map(transformItem)”[1]. Another (more) common scenario—but not yet relevant in JavaScript—is piping/composing functions[2]. [1] https://en.wikipedia.org/wiki/Tacit_programming [2] https://github.com/tc39/proposal-pipeline-operator/wiki

TIL about https://github.com/tc39/proposal-pipeline-operator, which I am immediately looking forward to playing with once it gains traction Some Time From Now™ (I have no earnest reason to transpile)

There's also a Stage 2 proposal for adding a pipe operator to JS[1] [1]: https://github.com/tc39/proposal-pipeline-operator

The pipeline operator |> exists in Elm[0]. It is available in bash as & and the popular (in my limited experience) package flow[1] also implements it as |> for readability. It is a proposed addendum to Javascript[2] but I have no idea how seriously the JS powers-that-be are taking that. The example you gave of Python doesn't have tagged union. I really don't know much at all about Python so maybe the type checker can tell you that you're handling all the cases, but with tagged union types you can have to handle every possible output of `str_if_zero` when calling it. That doesn't have to be an FP thing but I only find it when doing Elm and Haskell in my experience. [0] https://elm-lang.org/docs/syntax#operators [1] https://hackage.haskell.org/package/flow [2] https://github.com/tc39/proposal-pipeline-operator

The advancement of this proposal has been stalled for many years because there were two competing proposals. The winning proposal was with the Hack style pipelines, which won over the F# style pipelines. This decision is highly controversial as you can see if you look at the issue threads. One issue thread[1] got over 250 comments before it was closed as too heated. In my opinion the wrong proposal was advanced. And I find it very curios why this was advanced given how the lack of resolution. I’ve been following this proposal for a very long time and this feels like the committee went behind the community to make an executive decision based on their own believes. 1: https://github.com/tc39/proposal-pipeline-operator/issues/16...