Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PHP 8.5 adds pipe operator

thephp.foundation

Post reply on HN
Print view View original

221–230 of 282 posts

Re: PHP 8.5 adds pipe operator

#221

Post by hajile »

lexicality wrote: post #73
avaq wrote: post #54

Earlier quoted context omitted.

Not only have we been waiting for 10 years, the most likely candidate to go forward is not at all what we wanted when the proposal was created: We wanted a pipe operator that would pair well with unary functions (like those created by partial function application, which could get its own syntax), but that got rejected on the premise that it would lead to a programming style that utilizes too many closures[0], and whi…

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?

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 30-50% slower than non-private variables (and also break proxies).

* let/const are a few percent slower than var.

* Generators are slower than loops.

* Iterators are often slower due to generating garbage for return values.

* Rest/spread operators hide that you're allocating new arrays and objects.

* Proxies cause insane slowdowns of your code.

* Allowing sub-classing of builtins makes everything slow.

* BigInt as designs is almost always slower than the engine's inferred 31-bit integers.

Meanwhile, Google and Mozilla refuse to implement proper tail calls even though they would INCREASE performance for a lot of code. They killed their SIMD projects (despite having them already implemented) which also reduced performance for the most performance-sensitive applications.

It seems obvious that performance is a non-issue when it's something they want to add and an easy excuse when it's something they don't want to add.

Re: PHP 8.5 adds pipe operator

#222

Post by gylterud »

dmead wrote: post #204
gylterud wrote: post #192

Earlier quoted context omitted.

What makes you believe Haskell is dead or even dying? New versions of GHC are coming out, and in my experience, developing Haskell has never been smoother (that’s not to say it is completely smooth).

it's easy to learn and speak latin as well.

Yes, but there is very little modern latin slang. While GHC gives us great new extensions of Haskell quite often.

Re: PHP 8.5 adds pipe operator

#224

Post by procaryote »

hombre_fatal wrote: post #219
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')…

The problem with intermediate assignment is that they pollute your scope. You might have $values and then you transform it into $b, $values2, $foo, $whatever, and your code has to be eternally vigilant that it never accidentally refers to $values or any of the intermediate variables ever again since they only existed in service to produce some downstream result. Sometimes this is slightly better in languages that let…

Put it in a function and the scope you pollute is only as big as you make it.

Re: PHP 8.5 adds pipe operator

#225

Post by adius »

PHP getting a pipe operator with ways to implement a Maybe Monad was definitely not on my 2025 bingo card.

But any changes making mainstream languages more functional are highly welcome! It’s just more ergonomic than imperative code.

Re: PHP 8.5 adds pipe operator

#226

Post by chriswarbo »

dmead wrote: post #203
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).

yea I agree. haskell was my primary language for several years in the 00s. it's since had almost zero industry uptake. Don't come at me with jane street or the one off startup. I thought for a while I'd be able to focus on getting jobs that liked haskell. it never happened.

I certainly wouldn't focus on getting a Haskell job. Yet they are out there; e.g. my current job is Haskell, and happens to be in the same sector (public transport) as my last job (which was mostly Scala).

Also, I've found Haskell appropriate for some one-off tasks over the years, e.g.

- Extracting a load of cross-referenced data from a huge XML file. I tried a few of our "common" languages/systems, but they all ran out of memory. Haskell let me quickly write something efficient-enough. Not sure if that's ever been used since (if so then it's definitely tech debt).

- Testing a new system matched certain behaviours of the system it was replacing. This was a one-person task, and was thrown away once the old system was replaced; so no tech debt. In fact, this was at a PHP shop :)

Re: PHP 8.5 adds pipe operator

#227

Post by hombre_fatal »

procaryote wrote: post #224
hombre_fatal wrote: post #219

Earlier quoted context omitted.

The problem with intermediate assignment is that they pollute your scope. You might have $values and then you transform it into $b, $values2, $foo, $whatever, and your code has to be eternally vigilant that it never accidentally refers to $values or any of the intermediate variables ever again since they only existed in service to produce some downstream result. Sometimes this is slightly better in languages that let…

Put it in a function and the scope you pollute is only as big as you make it.

Functions also pollute the scope the same way. And you don't want to be forced to extract a function that is never reused just to hide intermediate values; you should only have to extract a function when you want the abstraction.

The pipeline transformation specifically lets you clean this up with functions at the scope of each ephemeral intermediate value.

Re: PHP 8.5 adds pipe operator

#228

Post by daneel_w »

Mystery-Machine wrote: post #188

PHP: $result = $arr |> fn($x) => array_column($x, 'tags') // Gets an array of arrays |> fn($x) => array_merge(...$x) // Flatten into one big array |> array_unique(...) // Remove duplicates |> array_values(...) // Reindex the array. ; // Ruby: result = arr.uniq.flatten.map(&:tags) I understand this is not pipe operator, but just look at that character difference across these two languages. // This comment was my $0.02…

Putting the delimiter on a line of its own is a syntactical trick that helps bringing small additions down to a neater 1-line diff instead of a 2-line diff. You've probably run into it many times before in other contexts without thinking of it. Arrays/hashes, quoted multi-line strings etc.

Re: PHP 8.5 adds pipe operator

#229

Post by gbalduzzi »

goykasi wrote: post #211
gbalduzzi wrote: post #179

Earlier quoted context omitted.

And that was fine in the early days, absolutely. We are not in the early days though, and in many other aspects PHP evolved greatly.

What are the benefits? Code completion, AI agents, etc will handle it for you. No one's life is falling apart because the param ordering is more similar to C than a blog article complaining about it decade ago. Php devs have had up 30 years to learn the difference. Are C devs complaining about this? If we want to change the param order of str/array functions for php, I think we should start with fixing the C librarie…

Because it would be more predictable, easier to memorize, less verbose, easier to use for developers coming from other modern languages and more comfortable to work with.

The fact that they are chaotic since 30 years ago is not a valid reason for keeping them chaotic right now.

Also, I'm not even arguing they should change the existing functions, that would break all existing code for almost no reason.

I think they should "simply" support methods on primitives, and implement the main ones in a chainable way:

"test string"->trim()->upper()->limit(100);

[0,1,2]->filter(fn ($n) => $n % 2 === 0)->map(fn($n) => $n * 2);

I would love this so much

Re: PHP 8.5 adds pipe operator

#230

Post by hajile »

wouldbecouldbe wrote: post #3
bapak wrote: post #2

Meanwhile the JS world has been waiting for 10 years for this proposal, which is still in stage 2 https://github.com/tc39/proposal-pipeline-operator/issues/23...

It’s really not needed, syntax sugar. With dots you do almost the same. Php doesn’t have chaining. Adding more and more complexity doesn’t make a language better.

Chaining requires creating a class and ensuring everything sticks to the class and returns it properly so the chain doesn't blow up. As you add more options and do more stuff, this becomes increasingly hard to write and maintain.

If I'm using a chained library and need another method, I have to understand the underlying data model (a leaky abstraction) and also must have some hack-ish way of extending the model. As I'm not the maintainer, I'm probably going to cause subtle breakages along the way.

Pipe operators have none of these issues. They are obvious. They don't need to track state past the previous operator (which also makes debugging easier). If they need to be extended, look at your response value and add the appropriate function.

Composition (whether with the pipe operator or not) is vastly superior to chaining.

Post reply on HN