4 ms·

I love the pipe operator - one of the things I dig about Elixir though many languages have it. It's so much easier to reason about: $result = $arr |> fn(

I love the pipe operator - one of the things I dig about Elixir though many languages have it. It's so much easier to reason about: $result = $arr |> fn($x) => array_column($x, 'tags') |> fn($x) => array_merge(...$x) |> array_unique(...) |> array_values(...) VS array_values(array_unique(array_merge(...array_column($arr, 'tags'))));

qwertox 1y ago
I don't see how this is hard to reason about, assuming this is the resulting code when using variables: $tags = ...array_column($arr, 'tags'); $merged_tags = array_merge($tags); $unique_tags = array_unique($merged_tags); $tag_values = array_values($unique_tags); It also makes it easier to inspect the values after each step.
- r34 1y ago
  Your version includes 4 variables. Pipes don't create those intermediate variables, so they are more memory efficient. Readability is mostly matter of habit. One reads easily what he/she is used to read.
  - girvo 1y ago
    > so they are more memory efficient They can be. It depends on the language, interpreter, compiler, and whether you do anything with those intermediate variables and the optimiser can get rid of them.
    - r34 1y ago
      I thought we are talking about PHP8.5:)
      - girvo 1y ago
        Ah, I thought we were talking more generally about PL constructs that let you avoid intermediate variables, apologies :)
  - qwertox 1y ago
    It's true that pipes are more readable, and for many cases they will be the better option, but the example of nested functions just doesn't hold. That's like saying someone would use this: $result = $arr |> fn($x) => array_column($x, 'tags') |> fn($x) => array_merge(...$x) |> array_unique(...) |> array_values(...) which is harder to reason about than the nested functions. array_values( array_unique( array_merge( ...array_column($arr, 'tags') ) ) ); or array_values( array_unique( array_merge( ...array_column($arr, 'tags') ) ) );
    - navalino 1y ago
      It is more readable and better option — you have to parse it from the innermost function to the outermost just to understand what it's doing. With the pipe, it's more straightforward: you read it step by step — do this, then that, then the next — just like how you'd naturally read instructions.
    - account42 1y ago
      The pipe syntax is much more readable than nested function calls when you need additional arguments for intermediate functions. With nested functions it becomes hard to see which functions those arguments belong to even if you try to help it with formatting.
    - troupo 1y ago
      Why didn't you format the pipes, too? $result = $arr |> fn($x) => array_column($x, 'tags') |> fn($x) => array_merge(...$x) |> array_unique(...) |> array_values(...) vs array_values( array_unique( array_merge( ...array_column($arr, 'tags') ) ) ); With pipes you have linear sequence of data transformations. With nested function calls you have to start with innermost function and proceed all the way top the outermost layer.
      - qwertox 1y ago
        Because they were already formatted that way to begin with.
- cess11 1y ago
  Such variable threading tends to be harder to skim through in production code, the intermediates become noise that's harder to filter out than a repeated symbol like |>. Preferably you should also be sure that the functions are compatible with the data type going in and only rarely have to break it to dump data mid-chain. If you expect that kind of erroring it's likely a builder-chain with -> is a better alternative and do logging in the methods.
- jeroenhd 1y ago
  Correctly naming things is one of the harder challenges in computer programming. Putting effort into naming intermediates that you're going to throw out is a waste. Plus, the more variables you introduce, the more likely you'll accidentally re-use a variable name somewhere down the line. With PHP allowing variable initialization in one branch but not the other, and continuing execution by default when an undeclared variable is passed, declaring more variables can lead to an annoying class of bugs that would require significant (breaking) changes to the core language to completely eliminate.
- agos 1y ago
  I don't think inspecting this is easier than adding |> IO.inspect() to a pipe chain
  - harg 1y ago
    Or putting `|> dbg()` at the end and let it print the value at every step of the chain
  - wraptile 1y ago
    modifying code just to attach a breakpoint is kinda silly in this day and age.
- lawn 1y ago
  Introducing a new variable every single line adda a bunch of cognitive load compared to the pipe operator. It's much easier skim with the pipe operator and it's more robust too (for example reordering is a pain with variables, it's easy to introduce errors).
- kristopolous 1y ago
  It's easier to write, copy paste, compose and comment
- const_cast 1y ago
  The main problem with this approach, as someone who programs in PHP daily, is it pollutes the scope. That makes debugging much, much harder - you lose track of variables, and the current state of the program is complicated. IMO, if a value is a throwaway, like an intermediate, we shouldn't be able to use it. So method chaining or nesting function calls prevents them. Then, when we break after these functions, we can't see fake values. It also prevents someone in the future mutating the throwaway values. Someone could easily insert logic or a call that mutates something in the middle of this and breaks the chain. One way this is prevented in PHP is just using functions. But then you have functions just for the sake of scope, which isn't really what they're for. That introduces other annoyances.
someothherguyy 1y ago
> It's so much easier to reason about Is it though? I don't think so.
- andrewflnr 1y ago
  It tends to work a little better in Elixir, because you very rarely have to include one-off lambdas in your pipeline. The standard library functions are designed to work with the pipeline operator, where the thing you probably want to thread through is usually the first argument.

qwertox 1y ago

I don't see how this is hard to reason about, assuming this is the resulting code when using variables: $tags = ...array_column($arr, 'tags'); $merged_tags = array_merge($tags); $unique_tags = array_unique($merged_tags); $tag_values = array_values($unique_tags); It also makes it easier to inspect the values after each step.

r34 1y ago
Your version includes 4 variables. Pipes don't create those intermediate variables, so they are more memory efficient. Readability is mostly matter of habit. One reads easily what he/she is used to read.
- girvo 1y ago
  > so they are more memory efficient They can be. It depends on the language, interpreter, compiler, and whether you do anything with those intermediate variables and the optimiser can get rid of them.
  - r34 1y ago
    I thought we are talking about PHP8.5:)
    - girvo 1y ago
      Ah, I thought we were talking more generally about PL constructs that let you avoid intermediate variables, apologies :)
- qwertox 1y ago
  It's true that pipes are more readable, and for many cases they will be the better option, but the example of nested functions just doesn't hold. That's like saying someone would use this: $result = $arr |> fn($x) => array_column($x, 'tags') |> fn($x) => array_merge(...$x) |> array_unique(...) |> array_values(...) which is harder to reason about than the nested functions. array_values( array_unique( array_merge( ...array_column($arr, 'tags') ) ) ); or array_values( array_unique( array_merge( ...array_column($arr, 'tags') ) ) );
  - navalino 1y ago
    It is more readable and better option — you have to parse it from the innermost function to the outermost just to understand what it's doing. With the pipe, it's more straightforward: you read it step by step — do this, then that, then the next — just like how you'd naturally read instructions.
  - account42 1y ago
    The pipe syntax is much more readable than nested function calls when you need additional arguments for intermediate functions. With nested functions it becomes hard to see which functions those arguments belong to even if you try to help it with formatting.
  - troupo 1y ago
    Why didn't you format the pipes, too? $result = $arr |> fn($x) => array_column($x, 'tags') |> fn($x) => array_merge(...$x) |> array_unique(...) |> array_values(...) vs array_values( array_unique( array_merge( ...array_column($arr, 'tags') ) ) ); With pipes you have linear sequence of data transformations. With nested function calls you have to start with innermost function and proceed all the way top the outermost layer.
    - qwertox 1y ago
      Because they were already formatted that way to begin with.
cess11 1y ago
Such variable threading tends to be harder to skim through in production code, the intermediates become noise that's harder to filter out than a repeated symbol like |>. Preferably you should also be sure that the functions are compatible with the data type going in and only rarely have to break it to dump data mid-chain. If you expect that kind of erroring it's likely a builder-chain with -> is a better alternative and do logging in the methods.
jeroenhd 1y ago
Correctly naming things is one of the harder challenges in computer programming. Putting effort into naming intermediates that you're going to throw out is a waste. Plus, the more variables you introduce, the more likely you'll accidentally re-use a variable name somewhere down the line. With PHP allowing variable initialization in one branch but not the other, and continuing execution by default when an undeclared variable is passed, declaring more variables can lead to an annoying class of bugs that would require significant (breaking) changes to the core language to completely eliminate.
agos 1y ago
I don't think inspecting this is easier than adding |> IO.inspect() to a pipe chain
- harg 1y ago
  Or putting `|> dbg()` at the end and let it print the value at every step of the chain
- wraptile 1y ago
  modifying code just to attach a breakpoint is kinda silly in this day and age.
lawn 1y ago
Introducing a new variable every single line adda a bunch of cognitive load compared to the pipe operator. It's much easier skim with the pipe operator and it's more robust too (for example reordering is a pain with variables, it's easy to introduce errors).
kristopolous 1y ago
It's easier to write, copy paste, compose and comment
const_cast 1y ago
The main problem with this approach, as someone who programs in PHP daily, is it pollutes the scope. That makes debugging much, much harder - you lose track of variables, and the current state of the program is complicated. IMO, if a value is a throwaway, like an intermediate, we shouldn't be able to use it. So method chaining or nesting function calls prevents them. Then, when we break after these functions, we can't see fake values. It also prevents someone in the future mutating the throwaway values. Someone could easily insert logic or a call that mutates something in the middle of this and breaks the chain. One way this is prevented in PHP is just using functions. But then you have functions just for the sake of scope, which isn't really what they're for. That introduces other annoyances.

someothherguyy 1y ago

> It's so much easier to reason about Is it though? I don't think so.

andrewflnr 1y ago
It tends to work a little better in Elixir, because you very rarely have to include one-off lambdas in your pipeline. The standard library functions are designed to work with the pipeline operator, where the thing you probably want to thread through is usually the first argument.