3 ms·

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

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

zarzavat 5y ago
What type is result? In TypeScript you'd have to give it an any type which means you lose type checking.
joshum97 5y ago
This looks a lot better with the F# proposal: return cb(predicate) |> negate |> filter;
chrisco255 5y ago
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.
- thomas_moon 5y ago
  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
dragonwriter 5y ago
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.
- thomas_moon 5y ago
  You're right, my mistake. Believe it or not, it wasn't intentional and I just completely spaced. Edited to be much closer.

zarzavat 5y ago

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

joshum97 5y ago

This looks a lot better with the F# proposal: return cb(predicate) |> negate |> filter;

chrisco255 5y ago

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.

thomas_moon 5y ago
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

dragonwriter 5y ago

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.

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