9 ms·

It's annoying to have to decide on and write out so many names. The intermediary names are not relevant to solving the problem. This is so much less noisy:

It's annoying to have to decide on and write out so many names. The intermediary names are not relevant to solving the problem. This is so much less noisy: value |> one |> two |> three

vikingerik 4y ago
The intermediary names are extremely relevant to the next poor sucker who has to understand what you were trying to do. Code is read far more than it is written. Use temporary variables. Put in the effort to name them once, and then that effort pays back every time anyone needs to read and understand the code.
- masklinn 4y ago
  > The intermediary names are extremely relevant to the next poor sucker who has to understand what you were trying to do. There are lots of cases where they’re not and are just noise written in exactly the style of the original comment. Or worse all the one-shot temporaries get assigned to the same worthless name. Unless you live and die by the mantra that no expression can have more than one period, pipes pretty much just bring attribute/method chaining to arbitrary functions and expressions.
- substation13 4y ago
  > The intermediary names are extremely relevant to the next poor sucker who has to understand what you were trying to do. I just don't think that this is always true. Consider: const highestScore = players |> filter(x => x.isAlive) |> map(x => x.score) |> tryMax I don't see how this is better: const alivePlayers = filter(x => x.isAlive)(players); const scoresOfalivePlayers = map(x => x.score)(alivePlayers); const highestScore = tryMax(scoresOfalivePlayers); And you can add helpful comments to pipeline code if needed: const highestScore = players |> filter(x => x.isAlive) // Dead players cannot win |> map(x => x.score) |> tryMax More generally though, I don't see why forcing everyone to write out intermediary names all of the time leads to more readable code. If it's more readable to do so, I will. If a pipeline is more readable, why should we be prevented from using it?
  - charles_f 4y ago
    > I don't see how this is better Case in point: > you can add helpful comments to pipeline code if needed The pipeline with explanatory variables explain to you what the steps are with code. Using pipeline you need to add comments to explain "what" you are doing.
    - substation13 4y ago
      Then you can mix-and-match: const activePlayers = players |> filter(x => x.isAlive) const highestScore = activePlayers |> map(x => x.score) |> tryMax In any case, I don't see how being restricted to always using an intermediary variable for every step is an advantage.
    - dalmo3 4y ago
      And then it's a pleasure to open the debugger and immediately see the values for each step.
      - substation13 4y ago
        If pipes are added to JS then IDE support will follow very swiftly.
  - vikingerik 4y ago
    > I don't see how this is better: const alivePlayers = filter(x => x.isAlive)(players); const scoresOfalivePlayers = map(x => x.score)(alivePlayers); const highestScore = tryMax(scoresOfalivePlayers); I think this is way better. The variable names tell me at an instantaneous glance what each clause is doing. I don't have to spend mental effort delving into what's going on with the lambdas, or scan back and forth to find a comment that may or may not be there or out of date if it is. Furthermore, I'd wrap all of those lines together into a getHighestScore() function as well. That makes the complexity exactly as visible or as abstracted as you want at any given moment. The name of that function tells you what the aggregate of the operations is doing, and you can go look inside that function if you want to see the individual steps.
danwee 4y ago
It's only less noisy because of the simplistic nature of the example. In real world code, `one`, `two` and `three` and probably a chunk of code put together in a single line and it's difficult to find out what the hell they are doing. Concat together a few of these and that's a recipe for disaster. Less experienced engineers would add a comment at the top of the pipe chain explaining what's going on. More experienced engineers would divide and conquer and use temporary named variables (render commets useless).
- charles_f 4y ago
  Agreed. I'm not the one coming up with the one/two/three, I took it from the proposition. Explanatory variables help understand the steps of the process, this |> operator is receipe for unmaintainable, expedited code.

It's annoying to have to decide on and write out so many names. The intermediary names are not relevant to solving the problem. This is so much less noisy: value |> one |> two |> three

vikingerik 4y ago

The intermediary names are extremely relevant to the next poor sucker who has to understand what you were trying to do. Code is read far more than it is written. Use temporary variables. Put in the effort to name them once, and then that effort pays back every time anyone needs to read and understand the code.

masklinn 4y ago
> The intermediary names are extremely relevant to the next poor sucker who has to understand what you were trying to do. There are lots of cases where they’re not and are just noise written in exactly the style of the original comment. Or worse all the one-shot temporaries get assigned to the same worthless name. Unless you live and die by the mantra that no expression can have more than one period, pipes pretty much just bring attribute/method chaining to arbitrary functions and expressions.
substation13 4y ago
> The intermediary names are extremely relevant to the next poor sucker who has to understand what you were trying to do. I just don't think that this is always true. Consider: const highestScore = players |> filter(x => x.isAlive) |> map(x => x.score) |> tryMax I don't see how this is better: const alivePlayers = filter(x => x.isAlive)(players); const scoresOfalivePlayers = map(x => x.score)(alivePlayers); const highestScore = tryMax(scoresOfalivePlayers); And you can add helpful comments to pipeline code if needed: const highestScore = players |> filter(x => x.isAlive) // Dead players cannot win |> map(x => x.score) |> tryMax More generally though, I don't see why forcing everyone to write out intermediary names all of the time leads to more readable code. If it's more readable to do so, I will. If a pipeline is more readable, why should we be prevented from using it?
- charles_f 4y ago
  > I don't see how this is better Case in point: > you can add helpful comments to pipeline code if needed The pipeline with explanatory variables explain to you what the steps are with code. Using pipeline you need to add comments to explain "what" you are doing.
  - substation13 4y ago
    Then you can mix-and-match: const activePlayers = players |> filter(x => x.isAlive) const highestScore = activePlayers |> map(x => x.score) |> tryMax In any case, I don't see how being restricted to always using an intermediary variable for every step is an advantage.
  - dalmo3 4y ago
    And then it's a pleasure to open the debugger and immediately see the values for each step.
    - substation13 4y ago
      If pipes are added to JS then IDE support will follow very swiftly.
- vikingerik 4y ago
  > I don't see how this is better: const alivePlayers = filter(x => x.isAlive)(players); const scoresOfalivePlayers = map(x => x.score)(alivePlayers); const highestScore = tryMax(scoresOfalivePlayers); I think this is way better. The variable names tell me at an instantaneous glance what each clause is doing. I don't have to spend mental effort delving into what's going on with the lambdas, or scan back and forth to find a comment that may or may not be there or out of date if it is. Furthermore, I'd wrap all of those lines together into a getHighestScore() function as well. That makes the complexity exactly as visible or as abstracted as you want at any given moment. The name of that function tells you what the aggregate of the operations is doing, and you can go look inside that function if you want to see the individual steps.

danwee 4y ago

It's only less noisy because of the simplistic nature of the example. In real world code, `one`, `two` and `three` and probably a chunk of code put together in a single line and it's difficult to find out what the hell they are doing. Concat together a few of these and that's a recipe for disaster. Less experienced engineers would add a comment at the top of the pipe chain explaining what's going on. More experienced engineers would divide and conquer and use temporary named variables (render commets useless).

charles_f 4y ago
Agreed. I'm not the one coming up with the one/two/three, I took it from the proposition. Explanatory variables help understand the steps of the process, this |> operator is receipe for unmaintainable, expedited code.