PHP 8.5 adds pipe operator

Post by 8n4vidtmkvmk » Tue, Aug 05, 2025, 5:03 PM UTC

drakythe wrote: post #196

donatj wrote: post #142

I had this argument in the PHP community when the feature was being discussed, but I think the syntax is much more complicated to read , requiring backtracking to understand. It might be easier to write. Imagine you're just scanning code you're unfamiliar with trying to identify the symbols. Make sense of inputs and outputs, and you come to something as follows. $result = $arr |> fn($x) => array_column($x, 'values')…

I don't disagree with you. I had trouble reading the examples at first. But what immediately struck me is this syntax is pretty much identical to chaining object methods that return values. $result = $obj->query($sqlQuery)->fetchAll()[$key] so while the syntax is not my favorite, it at least maintains consistency between method chaining and now function chaining (by pipe).

Post by WorldMaker » Tue, Aug 05, 2025, 5:09 PM UTC

troupo wrote: post #181

donatj wrote: post #142

I had this argument in the PHP community when the feature was being discussed, but I think the syntax is much more complicated to read , requiring backtracking to understand. It might be easier to write. Imagine you're just scanning code you're unfamiliar with trying to identify the symbols. Make sense of inputs and outputs, and you come to something as follows. $result = $arr |> fn($x) => array_column($x, 'values')…

> I think the syntax is much more complicated to read, requiring backtracking to understand. Same as with `array_merge(...array_column($arr, 'values'));` or similar nested function calls. > Imagine you're just scanning code you're unfamiliar with trying to identify the symbols. Make sense of inputs and outputs, and you come to something as follows. We don't have to imagine :) People working in languages supporting pi…

Post by epolanski » Tue, Aug 05, 2025, 5:25 PM UTC

gylterud wrote: post #220

epolanski wrote: post #199

Earlier quoted context omitted.

And yet, while PHPs, Javas, and even nicher/newer languages like Kotlin, Clojure or Scala have plenty of killer software (software that makes it worth learning a language just to use that library/framework) Haskell has none after 30 years. Zero. Mind you, I know and like Haskell, but its issues are highly tied to the failure of the simple haskell initiative (also the dreadful state of its tooling).

There are lots of great libraries, like repa, servant, megaparsec, gloss, yampa… as well as bindings to lots of standard stuff. I consider parsing to be one of Haskell’s killer strengths and I would definitely use it to write a compiler. There is also some popular user facing software like Pandoc, written in Haskell. And companies using it internally.

Post by ufo » Tue, Aug 05, 2025, 5:30 PM UTC

jeroenhd wrote: post #117

lexicality wrote: post #73

Earlier quoted context omitted.

Am I correct in my understanding that you're saying that the developers of the most widely used JS engine saying "hey we can't see a way to implement this without tanking performance" is a silly hypothetical that should be ignored?

With JS' async/await system basically running on creating temporary closures, I don't think things will change all that much to be honest. Furthermore, I don't see why engines should police what is or isn't acceptable performance. Using functional interfaces (map/forEach/etc.) is slower than using for loops in most cases, but that didn't stop them from implementing those interfaces either. I don't think there's that…

    const x = fun1(a, 10)
    const y = fun2(x, 20)
    const z = fun3(y, 30)

    a |> ((a) => fun1(a, 10))
      |> ((x) => fun2(x, 20))
      |> ((y) => fun3(y, 30))

Post by hajile » Tue, Aug 05, 2025, 5:39 PM UTC

int_19h wrote: post #238

hajile wrote: post #221

Earlier quoted context omitted.

Closures won over OOP in Javascript a long time ago (eg, React switching from classes to functions + closures), but they still keep trying to force garbage like private variables on the community. Loads of features have been added to JS that have worse performance or theoretically enable worse performance, but that never stopped them before. Some concrete (not-exhaustive) examples: * Private variables are generally 3…

> * Rest/spread operators hide that you're allocating new arrays and objects. Only in function calls, surely? If you're using spread inside [] or {} then you already know that it allocates.