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

231–240 of 282 posts

Re: PHP 8.5 adds pipe operator

#231

Post by tracker1 »

sumeetdas wrote: post #138

The first typed programming language where I've seen pipe operator |> in action was in F#. You can write something like: sum 1 2 |> multiply 3 and it works because |> pushes the output of the left expression as the last parameter into the right-hand function. multiply has to be defined as: let multiply b c = b \* c so that b becomes 3, and c receives the result of sum 1 2 . RHS can also be a lambda too: sum 1 2 |> (f…

It's kind of wild that PHP gets a pipe(line) operator before JS finalizes its' version... of course they've had multiple competing proposals, of which I liked the F# inspired one the most... I've stopped relying on the likes of Babel (too much bloat) or I'd like to be able to use it. I used it for years for async functions and module syntax before they were implemented in node and browsers. Now it's hard to justify.

Re: PHP 8.5 adds pipe operator

#233

Post by tracker1 »

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 it's more a matter of what you're used to. It's simply an operator and syntax that you aren't used to seeing. Like if they added back a character into English that you aren't familiar with and started using it in words that you no longer recognize.

A lot of people could say the same of the rest/spread syntax as well.

Re: PHP 8.5 adds pipe operator

#234

Post by tracker1 »

hajile wrote: post #221
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?

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…

I wish I could upvote this more than once. I really liked the F# inspired pipe operator proposal and even used it a bit when I used to lean on 6to4/babel more, but it just sat and languished forever it seems. I can't really think of any other language feature I've seen since that I would have wanted more. The new Temporal being one exception.

Re: PHP 8.5 adds pipe operator

#235

Post by dmead »

chriswarbo wrote: post #226
dmead wrote: post #203

Earlier quoted context omitted.

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…

Yea of course, its not really the focus for me either way. my point was that how great haskell seemed in grad school didn't match up with the real world interest.

I use spark for most tasks like that now. Guido stole enough from haskell that pyspark is actually quite appealing for a lot of these tasks.

Re: PHP 8.5 adds pipe operator

#236

Post by int_19h »

rpeden wrote: post #207
sumeetdas wrote: post #138

The first typed programming language where I've seen pipe operator |> in action was in F#. You can write something like: sum 1 2 |> multiply 3 and it works because |> pushes the output of the left expression as the last parameter into the right-hand function. multiply has to be defined as: let multiply b c = b \* c so that b becomes 3, and c receives the result of sum 1 2 . RHS can also be a lambda too: sum 1 2 |> (f…

Is |> actually an operator in F#? I think it's just a regular function in the standard library but maybe I'm remembering incorrectly.

All operators are functions in F#, e.g. this is valid: (+) 1 2

Re: PHP 8.5 adds pipe operator

#237

Post by int_19h »

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')…

It's no different than chained property accesses or method calls, or more generally nested expressions. Which is to say, if you overuse it, you hamper readability, but if you have a named result for every single operation, it is also hard to read because it introduces too much noise.

Re: PHP 8.5 adds pipe operator

#238

Post by int_19h »

hajile wrote: post #221
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?

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.

Re: PHP 8.5 adds pipe operator

#239

Post by 1-more »

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.

Latin never paid my mortgage. Helped on the SATs though.

Re: PHP 8.5 adds pipe operator

#240

Post by 8n4vidtmkvmk »

xienze wrote: post #174
philjohn wrote: post #171

Earlier quoted context omitted.

This is what a good IDE brings to the table, it'll show that $result is of type string. The pipe operator (including T_BLING) was one of the few things I enjoyed when writing Hack at Meta.

> This is what a good IDE brings to the table, it'll show that $result is of type string. I think the parent is referring to what the result _means_, rather than its type. Functional programming can, at times, obfuscate meaning a bit compared to good ol’ imperative style.

If you want meaning, don't call your variable "result"
Post reply on HN