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

PHP 8.5

stitcher.io

Post reply on HN
Print view View original

61–70 of 197 posts

Re: PHP 8.5

#61

Post by ljm »

dotancohen wrote: post #10
f311a wrote: post #7

PHP becomes a complex language with each update. For what reason? Its application is still limited to the web, mostly.

I downvoted you before reading the fine article. I'm back to correct that. The new array_first() and array_last() functions are nice, everything else is either reimplantation of existing features or "features"which will make maintainability more difficult. The pipe operator is one such example. I don't need it - these nested methods are not really an issue in any codebase I've seen. The new syntax only works for unar…

The pipe operator makes it much easier to create home-grown cryptographic hash functions, as everybody used to do in the early 2000s:

    md5($password)
    |> sha1(...)
    |> sha1(...)
    |> md5(...)
    |> rot13(...)
    |> crc32(...)

Re: PHP 8.5

#62

Post by xonre »

PHP should do a real major compatibility break and remove $ sigil from variable names. It's gonna be worth the pain!

Re: PHP 8.5

#63

Post by f311a »

Xenoamorphous wrote: post #11
f311a wrote: post #7

PHP becomes a complex language with each update. For what reason? Its application is still limited to the web, mostly.

The web is not getting any simpler.

I don't see how making a language more complex can help with that. Complex languages makes sense for system programming where you want to squeeze some performance.

Re: PHP 8.5

#65

Post by ThatMedicIsASpy »

calpaterson wrote: post #5

A lot of people are too proud to be associated with PHP. I am ready to admit that know nothing about the language except that a lot of people make cool things with it. My favourite PHP product at the moment is BookStack ( https://www.bookstackapp.com/ ), a really good wiki. I run an instance for my family and it's great. But there are loads of things. And I notice that many of the sites I like using...are built on we…

https://github.com/AzuraCast/AzuraCast

AzuraCast because I like learning by looking at code and hosting my own radio/music

Re: PHP 8.5

#66

Post by dotancohen »

ljm wrote: post #61
dotancohen wrote: post #10

Earlier quoted context omitted.

I downvoted you before reading the fine article. I'm back to correct that. The new array_first() and array_last() functions are nice, everything else is either reimplantation of existing features or "features"which will make maintainability more difficult. The pipe operator is one such example. I don't need it - these nested methods are not really an issue in any codebase I've seen. The new syntax only works for unar…

The pipe operator makes it much easier to create home-grown cryptographic hash functions, as everybody used to do in the early 2000s: md5($password) |> sha1(...) |> sha1(...) |> md5(...) |> rot13(...) |> crc32(...)

Oh, now I'm convinced!

Re: PHP 8.5

#67

Post by kreco »

holoduke wrote: post #34

Why is it that all these languages like PHP, but also typescript are becoming like impossible puzzles to read. I find these generics, types and other language features very often causing complex software architecture. I see so many collegues these days struggling in understanding codebases. You almost need a PHD brain to be a frontend web developer.

Like on of my sibling comment, I truly believe this is connected to some degree of social pressure.

People pointing fingers to "outdated" languages for not having some of the most trendy constructs.

The pipe operator is definitely one of the feature that create more ways to do the same thing while providing unclear benefit.

Never in my life I was in a situation like "with the pipe operator this I would have saved me hours of debugging/reading/creating code".

Re: PHP 8.5

#68

Post by dijit »

inovica wrote: post #28

I still love PHP. 23 years ago we created some encryption software for it and it is still going. I also run a PHP newsletter. There's still a strong community of people and whilst there are other languages which I also use (Python, Node.js) I still find myself gravitating towards PHP for fast and simple work The only issues I have. is that this is a 'double edged sword' in that PHP has become far more complex since t…

> 23 years ago we created some encryption software for it

ZEND?

I remember "nulling" software in the mid-00's and Zend was always a terrible ball-ache.

Which, if that was your project, is high praise. :)

Re: PHP 8.5

#69

Post by johannes1234321 »

senfiaj wrote: post #57
Cthulhu_ wrote: post #24

Earlier quoted context omitted.

And a pipe operator, which is also being discussed in a number of other languages.

It seems that pipe operator was introduced largely because PHP arrays and strings don't have "methods". You can't write something in "OOP" style: "some_string"->str_replace("some", "replacement")->strtoupper(). With PHPs array / string procedural way writing such chains is much bulkier. Pipe operator will somewhat reduce the boilerplate, but the native "OOP" style is still much better. Although there is a proposal fo…

No, the OOP style isn't better. The set of functions one can use in OOP is closed.

Imagine I want to AfD a custom string function for a feature which uPpErCaSeS every second letter as I need that for some purpose: I can't do in OOP style.

In OOP I could extend the string class, but most other parts of the code won't magically use my string type now.

Thus I have to create a free standing function for this (which probably also is better as I don't need internal state of thee object, thus livingnoutisde is good for encapsulation)

And thus my string function works different from other string functions.

    my_casing($string->trim())->substr(3);
(The example of course is non sensical and could be reordered, but we argue syntax)

Having them all be simple functions makes it equal.

Of course there are alternative approaches. C++ argues for years about "uniform call syntax" which would always allow "object style" function calls, which could also find non-memwbr functions where the first argument is of compatible type, but such a thing requires stricter (or even static) typing, this won't work in PHP.

Re: PHP 8.5

#70

Post by johannes1234321 »

xonre wrote: post #62

PHP should do a real major compatibility break and remove $ sigil from variable names. It's gonna be worth the pain!

Hello Perl 6!

Such a change makes it a completely different language with no compatibility. Thus all previous code is lost, no easy migration paths (especially for libraries which would like to support both during transition)

Post reply on HN