2 ms·
This is interesting. Pipe operators are a big win in declarative languages because they allow you to implement a pipeline of operations, which goes against decl
by ModernMech 5y ago
This is interesting. Pipe operators are a big win in declarative languages because they allow you to implement a pipeline of operations, which goes against declarative semantics. Sequencing is difficult to express declaratively, thus pipe operators.
But imperative languages are really good sequencing! The syntax for doing this in Javascript is ;
Maybe pipes will give you some syntax wins, but it's not a huge win the way it is in declarative languages. I feel like what we are seeing in general is a lot of the good ideas of declarative languages making their way into imperative languages, sometimes without the best rationale. I'm not really seeing anything compelling in this proposal. It focuses a lot on legibility, but is that the biggest win here?
And is it an unambiguous win? If you're going to go through all the trouble of adding this thing, it better be fore a really good reason with clear benefits that outweigh the costs. I worry that with some of the examples they give (probably the best cherry-picked ones they could find), I find the temporary vars version more understandable. Yeah there are fewer keystrokes, but I have not the slightest idea what this does:
|> chalk.dim(%, 'node', args.join(' '))
But I know exactly what this does:
const coloredConsoleText = chalk.dim(consoleText, 'node', args.join(' '));
Also, another reason this is not so great in Javascript is because the functions are impure. In pure functional languages you can chain functions together safely and with certainty because you know:
1) input arguments are immutable and will not be modified by the function
2) The function has no side effects.
Therefore you can run these pipelines multiple times with the same input and you know what output you're going to get.
If you have one or neither of these guarantees, then it's the wild west. What happens to the arguments when they go into that function? Are they mutated? Are they shared with another thread/process/worker? Are there any system calls in there? File IO? HTTP Requests?
With this proposal, you have all these side channels that can be used and no guarantees about mutability or idempotency, or even whether or not the variables will have the same type after they are passed into a function. This just seems like the makings of a huge mess to me.