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

41–50 of 197 posts

Re: PHP 8.5

#41

Post by greiskul »

s1mplicissimus wrote: post #14
jojobas wrote: post #13

Earlier quoted context omitted.

Probably not, but not most languages are not inviting to do them.

Give me an example where PHP invites developers to do terrible things and I'll show you 2 other popular languages that invite equally bad or worse things :) Or as Bjarne Stroustrup put it: There's two types of languages: The ones people complain about and the ones noone uses

The @ operator of php. In languages like Java, to silently catch all exceptions and do nothing with them requires at least some boiler plate.

PHP has an operator for something you should never do in a sane codebase.

You know that python wants good good to look good?

PHP was written in a way that makes bad code look good. And if we want Software Engineering to be a serious field that evolves, we have to be able to be honest with ourselves. It is a bad tool. Good programmers can even write good programs with bad tools. Doesn't mean you shouldn't avoid bad tools given the option.

There probably is a "PHP the good parts". But Javascript actually had a pretty nice core, and an utility of being in all web browsers that no other language could replicate. What niche does PHP have where it brings more value there other nicer languages can't be used instead?

Re: PHP 8.5

#42

Post by kijin »

rob74 wrote: post #35
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…

I'd take PHP instead of JS/TS + framework-of-the-day on the backend anytime. Ok, PHP is usually also paired with a framework ( cough Laravel cough ), but at least there the situation is more stable, not to mention more mature. Unfortunately, I'm not the only one making the decisions...

PHP is a reasonable choice if you care about writing something that will still work out of the box 10 years from now.

But of course this assumes that you work with a team that can see a year ahead, let alone 10.

Re: PHP 8.5

#43

Post by Yokolos »

babuskov wrote: post #36
Yokolos wrote: post #25

Earlier quoted context omitted.

You can do crazy things in every language. However, in a language like Java, the crazy things are more conceptual (factory for factory of factories) and not basic things like what does == mean or problems with weak typing and implicit conversions. A lot of the issues with PHP can be avoided in modern PHP using things like strict_types=1, but most of the time, we don't get to work with projects using best practices. A…

Funny that you picked == as an example when == is very counter intuitive in Java and is one of the common pitfalls for beginners: String a = new String(); String b = new String(); a = "test"; b = a + ""; if (a == "test") { // true } if (b == "test") { // false } if (a == b) { // false } Just like PHP, you have to read the docs to use it properly.

So you're going to ignore the rest of what I wrote? I'll just assume you agree with me and the rest of my comment, but you don't want to admit it. Works for me.

Re: PHP 8.5

#44

Post by pbowyer »

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 [...] syntax only works for unary functions, so higher arity functions must be wrapped in an arrow function.

It's coming - but to get PHP RFCs to pass they have to be salami-sliced, otherwise they're voted down.

https://wiki.php.net/rfc/partial_function_application_v2

Re: PHP 8.5

#45

Post by ffsm8 »

pjmlp wrote: post #38
darkamaul wrote: post #26

PHP's evolution since PHP 5 has been substantial, and I think this is a real problem. As someone who learned the language years ago, the pace of change (generics, attributes, match expressions, typed properties) makes modern codebases genuinely difficult to follow. I suspect this affects many developers who cut their teeth on PHP but haven't kept up. The language has become a different beast, which is a strength for…

This is true for most languages though, compare C# 14 with C# 1.0, Java 25 with Java 1.0, C 23 (plus common compiler extensions) with K&R C,....

I think he's thinking more along the lines of PHP 5-8.5

That version 1-latest is understandingly highly different, but these are all decades old languages, which barely changed for some time, but are now all introducing new syntax.

Which I think makes sense, but it's obviously going to leave 9-5 devs behind that don't particularly care for coding and want to invest as little time as possible into their language knowledge.

Re: PHP 8.5

#46

Post by onli »

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.

I assume it is some inferiority complex, on many sides. PHP itself was laughed at being too simple, underpowered and inconsistent, now they overcorrected with types, annotations and breaking backwards compatibility with every release so that no old code base can remain intact. Frontend devs yearned to be regarded as real developers, which in their context means construction of unwieldly and overcomplex enterprise bullshit, thus typescript etc. And in the backend you have that same mechanism, devs having to prove they are no beginners and thus using (wrongly) design patterns, instructed by software architects, instead of avoiding abstraction and thus complexity.

No, I'm not bitter.

Re: PHP 8.5

#47

Post by senfiaj »

phplovesong wrote: post #31

PHP should REALLY focus on getting the core stuff in shape. Its still so annoying that you have to use mb_real_uppercase($name) for unicode. The other gripe is that the stdlib is SO messy. With PHP 5.3 they had a once in a lifetime opportunity to cleanup the stdlib and introduce a new namespaced API for builtins, and optionally introduce a uniform function call syntax: "foo"->strtoupper(); Whenever doing PHP the time…

Yeah, the core ergonomics is significantly lagging behind most other backend languages despite improvements in some areas. I even wrote an article https://waspdev.com/articles/2025-06-12/my-honest-opinion-ab... .

As for concurrency/async, it's possible to do requests in parallel with curl_multi_*. Other async/prallel things are also possible, but tend to be more complicated compared to JS or other languages with promise and async support.

Re: PHP 8.5

#48

Post by onli »

greiskul wrote: post #41
s1mplicissimus wrote: post #14

Earlier quoted context omitted.

Give me an example where PHP invites developers to do terrible things and I'll show you 2 other popular languages that invite equally bad or worse things :) Or as Bjarne Stroustrup put it: There's two types of languages: The ones people complain about and the ones noone uses

The @ operator of php. In languages like Java, to silently catch all exceptions and do nothing with them requires at least some boiler plate. PHP has an operator for something you should never do in a sane codebase. You know that python wants good good to look good? PHP was written in a way that makes bad code look good. And if we want Software Engineering to be a serious field that evolves, we have to be able to be…

You absolutely can use @ in sane codebases. And you give the example yourself: In other languages you often enough see that boilerplate where thrown exception is discarded, because there is no sane reaction to some edge case and you just want the program to continue, because you know it will work anyway. And that's @.

Note though that @ was already neutered in some earlier recent PHP releases.

Re: PHP 8.5

#49

Post by pabs3 »

habibur wrote: post #27

Backticks as an alias for shell_exec() are deprecated Used that a lot in shell scripts. using php-cli. like in `mkdir $dirname`;

That is an anti-pattern, since it suffers from shell meta-character injection (and argument injection). Since PHP has mkdir, you should use that instead. And pcntl_exec() is the correct API for running processes.

Re: PHP 8.5

#50

Post by s1mplicissimus »

greiskul wrote: post #41
s1mplicissimus wrote: post #14

Earlier quoted context omitted.

Give me an example where PHP invites developers to do terrible things and I'll show you 2 other popular languages that invite equally bad or worse things :) Or as Bjarne Stroustrup put it: There's two types of languages: The ones people complain about and the ones noone uses

The @ operator of php. In languages like Java, to silently catch all exceptions and do nothing with them requires at least some boiler plate. PHP has an operator for something you should never do in a sane codebase. You know that python wants good good to look good? PHP was written in a way that makes bad code look good. And if we want Software Engineering to be a serious field that evolves, we have to be able to be…

The claim was "PHP invites bad code" - but your point is for "bad code can be written in PHP" which is really not the same thing. A quick google for the @ brought up https://stackoverflow.com/questions/136899/suppress-error-wi... where the highest voted response is ~"NO, don't use it please". No use case I've come across during the past 10 years has required or even nudged me in the direction of @. It's an ancient relic that the whole community considers a no-no. I'd be curious if you really want to argue that this state of affairs "invites" using the @.
Post reply on HN