3 ms·

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 writte

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.

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.