4 ms·

Example case?

slaymaker1907 5y ago
Stylistically I think it is most appropriate when you are writing conversions/cleanup/transformations. Places where method chaining is nice but not always possible. Suppose you are doing a bunch of string manipulation with custom string operations (maybe a custom regex engine with timeouts unlike the default JS regex API).
joshschreuder 5y ago
There’s an example in the article. > const y = h(g(f(x))) This example of nested function calls needs to be read from the inside out (execution is f, g, then h) which is unintuitive to how we read and parse text. The alternative is to use intermediate variables instead of nested function calls to represent the control flow of f, g, h.
- bern4444 5y ago
  I've come to prefer storing each intermediate value in its own variable. Debugging becomes a lot easier this way with a break point available at each step of the process. There's nearly no disadvantage to creating the extra variables given how quickly they can be cleaned up by the GC in these cases.
  - pacaro 5y ago
    Historically I would have agreed with this position, but debuggers have gotten a lot better, so it's typically possible to break wherever you need to. The intermediate variables still have value, just not as much as they used to, and they do (arguably) increase the cognitive load for the reader
    - colordrops 5y ago
      But intermediate variables are almost always better if named properly, as they provide a contextual name as to the purpose of the output of the function. Then only very minor downside is a bit more typing and more lines of code.
      - slaymaker1907 5y ago
        You forgot the biggest downside which is that naming things is hard. It also often causes important names to get lost in the jumble of temporary names.
- dragonwriter 5y ago
  > The alternative is to use intermediate variables That's one alternative. Another alternative is to use a function to apply functions in readable order (which effectively creates a context where “,” is the pipe operator.) const pipe = (x, ...fns) => funs.reduce((acc, fn) => fn(acc), x);
  - null_deref 5y ago
    IMO, I think this is far less readable than the pipe operator. Besides that how many times do you need to call three functions without additional parameters?
    - dragonwriter 5y ago
      > I think this is far less readable than the pipe operator I agree that pipe is more readable. I didn't say it was a better alternative, just one that is available. > Besides that how many times do you need to call three functions without additional parameters? That...depends on programming style, quite a lot.

Example case?

slaymaker1907 5y ago

Stylistically I think it is most appropriate when you are writing conversions/cleanup/transformations. Places where method chaining is nice but not always possible. Suppose you are doing a bunch of string manipulation with custom string operations (maybe a custom regex engine with timeouts unlike the default JS regex API).

joshschreuder 5y ago

There’s an example in the article. > const y = h(g(f(x))) This example of nested function calls needs to be read from the inside out (execution is f, g, then h) which is unintuitive to how we read and parse text. The alternative is to use intermediate variables instead of nested function calls to represent the control flow of f, g, h.

bern4444 5y ago
I've come to prefer storing each intermediate value in its own variable. Debugging becomes a lot easier this way with a break point available at each step of the process. There's nearly no disadvantage to creating the extra variables given how quickly they can be cleaned up by the GC in these cases.
- pacaro 5y ago
  Historically I would have agreed with this position, but debuggers have gotten a lot better, so it's typically possible to break wherever you need to. The intermediate variables still have value, just not as much as they used to, and they do (arguably) increase the cognitive load for the reader
  - colordrops 5y ago
    But intermediate variables are almost always better if named properly, as they provide a contextual name as to the purpose of the output of the function. Then only very minor downside is a bit more typing and more lines of code.
    - slaymaker1907 5y ago
      You forgot the biggest downside which is that naming things is hard. It also often causes important names to get lost in the jumble of temporary names.
dragonwriter 5y ago
> The alternative is to use intermediate variables That's one alternative. Another alternative is to use a function to apply functions in readable order (which effectively creates a context where “,” is the pipe operator.) const pipe = (x, ...fns) => funs.reduce((acc, fn) => fn(acc), x);
- null_deref 5y ago
  IMO, I think this is far less readable than the pipe operator. Besides that how many times do you need to call three functions without additional parameters?
  - dragonwriter 5y ago
    > I think this is far less readable than the pipe operator I agree that pipe is more readable. I didn't say it was a better alternative, just one that is available. > Besides that how many times do you need to call three functions without additional parameters? That...depends on programming style, quite a lot.