4 ms·

This strikes me as something better left to libraries. If you want to write in a functional style then Ramda, Lodash, Underscore, and plenty of others have pipe

by jsf01 4y ago

This strikes me as something better left to libraries. If you want to write in a functional style then Ramda, Lodash, Underscore, and plenty of others have pipe and compose functions. pipe(one, two, three) Easy to read. No new syntax. Extendable with arrow functions. Yes, there are some limitations in comparison to Hack Pipes. But those are far outweighed by not messing yet again with the language’s syntax.

scotty79 4y ago
For me limitations are killing 90% of usecases. In absence of |> % syntax I'd nearly always would go with intermediate temporary variables instead of pipe(). "point-free" syntax feels horrible for me and wrapping everything in lambdas feels excessive.
- disantlor 4y ago
  I use Ramda pipe() all the time and use a descriptively-named intermediate/temp variables wherever I might want to write a comment
Ross-Esmond 4y ago
This only applies to TypeScript, but error checking for this pattern from a library is much harder than error checking for native syntax. In order for TypeScript to check if the return value of one function has the correct type for the next function, you need to use generics, but generics don't allow for a variable number of generic parameters, so `pipe` would just have to use unknown or have dozens of overloads for each length of pipe usage (within reason). I know TypeScript is a different, optional language, and I see no reason why they couldn't add the feature without it being in JavaScript, but that's not generally how TypeScript operates. If JavaScript doesn't add it, TypeScript won't. There's also lots of tooling that will type check your JavaScript when available, which will benefit from a simpler model.
runarberg 4y ago
The problem with that is that it is impossible to infer the type of the n-ary pipe() function. Libraries “solve” this by overloading that function with n annotations, but that really isn’t a permanent solution, especially for libraries with millions of users, as there will always be a user that puts n + 1 parameters in that function.

by jsf01 4y ago

scotty79 4y ago

For me limitations are killing 90% of usecases. In absence of |> % syntax I'd nearly always would go with intermediate temporary variables instead of pipe(). "point-free" syntax feels horrible for me and wrapping everything in lambdas feels excessive.

disantlor 4y ago
I use Ramda pipe() all the time and use a descriptively-named intermediate/temp variables wherever I might want to write a comment

Ross-Esmond 4y ago

This only applies to TypeScript, but error checking for this pattern from a library is much harder than error checking for native syntax. In order for TypeScript to check if the return value of one function has the correct type for the next function, you need to use generics, but generics don't allow for a variable number of generic parameters, so `pipe` would just have to use unknown or have dozens of overloads for each length of pipe usage (within reason). I know TypeScript is a different, optional language, and I see no reason why they couldn't add the feature without it being in JavaScript, but that's not generally how TypeScript operates. If JavaScript doesn't add it, TypeScript won't. There's also lots of tooling that will type check your JavaScript when available, which will benefit from a simpler model.

runarberg 4y ago

The problem with that is that it is impossible to infer the type of the n-ary pipe() function. Libraries “solve” this by overloading that function with n annotations, but that really isn’t a permanent solution, especially for libraries with millions of users, as there will always be a user that puts n + 1 parameters in that function.