A proposal for adding a pipe operator to JavaScript

Re:A proposal for adding a pipe operator to JavaScript by thomas_moon on Tuesday October 19, 2021 @12:43PM (#28920212)

Seems to be trying to solve a problem that I would consider an anti pattern (attempting to 1 line everything). Someone else mentioned temporary vars and I think thats appropriate and equal if not better syntactically.

This example:

   // Status quo
   return filter(obj, negate(cb(predicate)), context);

   // With pipes
   return cb(predicate) |> _.negate(%) |> _.filter(obj, %, context);

Should in my opinion be written as:

   let result = cb(predicate)
   result = _.negate(result)
   result = _.filter(obj, result, context)

   return result

The main benefit of this is its experience and almost language agnostic. You see a variable defined and it's run through a series of functions before being returned. What's the point of removing a few characters?

edits: figure out how to format code, don't omit things

[ Parent | on HN ]

Re:A proposal for adding a pipe operator to JavaScript by joshum97 on Tuesday October 19, 2021 @12:49PM (#28920277)

This looks a lot better with the F# proposal:

    return cb(predicate) |> negate |> filter;

[ Parent | on HN ]

Re:A proposal for adding a pipe operator to JavaScript by chrisco255 on Tuesday October 19, 2021 @12:51PM (#28920313)

You're mutating result every step along the way and passing it into the functions as well, such that if it's an object or an array it could be mutated in non-transparent ways. The main benefit is to encourage a more functional, immutable data flow.

[ Parent | on HN ]

Re:A proposal for adding a pipe operator to JavaScript by thomas_moon on Tuesday October 19, 2021 @01:04PM (#28920496)

I get your point but I guess I fail to see how more obscure syntax at the time of composition helps someone understand something should be immutable. If I'm mutating inputs in a functional programming code base, syntax probably isn't the problem.

edit: wasn't to isn't

[ Parent | on HN ]

Re:A proposal for adding a pipe operator to JavaScript by zarzavat on Tuesday October 19, 2021 @09:38PM (#28925840)

What type is result? In TypeScript you'd have to give it an any type which means you lose type checking.

[ Parent | on HN ]

Re:A proposal for adding a pipe operator to JavaScript by dragonwriter on Tuesday October 19, 2021 @01:21PM (#28920722)

Your suggested code and the “status quo” code are not equivalent, and the with-pipes version isn't the conversion of either of the other two to the proposed pipes syntax.

Notably, on the first point, you proposed version drops two input variables from the other two versions, and on the second, the pipes version would correspond to the “status quo” version if the “_." prefixes were dropped.

It looks like you've made your proposed version look cleaner by both omitting required elements from it and adding unnecessary (and code-breaking) elements to the with-pipes version.

[ Parent | on HN ]

Re:A proposal for adding a pipe operator to JavaScript by thomas_moon on Tuesday October 19, 2021 @02:04PM (#28921330)

You're right, my mistake. Believe it or not, it wasn't intentional and I just completely spaced. Edited to be much closer.

[ Parent | on HN ]