PHP is a perfect example of how to undergo major transitions correctly.

In the time that it took Python to go from Python 2 to 3, PHP underwent 5.2 -> 5.3 and 5.6 -> 7.0. 5.3 changed how you write PHP in a fundamental way by introducing namespaces and PSR0 autoloading. Then, 5.6 -> 7.0 cleaned up the parser, resulting in massive speed improvements.

They did this by not breaking the universe in these major updates...or really, any of there updates. Each update would break a few specific things, warn you about a few other things that were going to break in the near future, while giving you ways to shim the old behavior if you _really_ needed it.

They also gave you ample carrots reasons to update - aside from what was already mentioned, my personal favorite update was PHP 5.4 because it introduced short array syntax, made UTF-8 the default charset, introduced traits, and finally put register globals and magic quotes out of their misery...but giving you a shim if you had some ancient project that needed it.

If you're wondering why PHP 6 was abandoned, it was because it was an update in the style of Python 3 by breaking strings everywhere. In retrospect, I think the decision to cancel 6 was the right one. Somehow, I doubt that PHP would've had the influx of data science and AI that saved Python 3.

Hats off to the project - I've long been off of the CGI-style web development narcotic, but the language put food on my table for quite some time, and the people steering the language treated their community well.

I've seen a few other comments also talk about PHP becoming more complex. However, I have "simple" code built using 5.3 and it works perfectly fine in 8. So I guess it CAN be complex, but doesn't really need to be. The biggest changes I would make to that code are fixing the multiple 'switch' and 'if/else' blocks to an anonymous function or some mapping... but it's not required.

> 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. :)

I think PHP 8 is easy to understand if you write it from scratch, you just have to learn doing things the right way, read up on PSRs and so on. It is a bit more complex but much more secure and supports quite a lot of things now that are definitely helpful to have.

IMO, newer PHP is still very readable. I programmed with C++ for a decade, but I can safely say that I cannot understand a modern C++ code base anymore.

I think PHP is way better now than it used to be. Learn PHP 8 and you are good to go.

It's a real problem with almost all software today, nothing ever gets done. they just keep piling unto it no matter how great it was. the idea of simplicity as a goal and feature is lost on this generation.

I dunno; I started with PHP 5 (actually, I think I started in late PHP 4), and I've only been happy with the changes as it's evolved.

The only one that's caused me any significant stress is the deprecation of the old `mysql` DB interface; I had to refactor a whole bunch of code for that, since I'm maintaining a codebase that's been in continuous use & development since 2001.

The additions to PHP since 5 add more things you can do, but they don't really change the simple things you can do to first learn PHP. You can still just create a .php file and start interspersing HTML and <?php script tags with basic operations.

but would you even be considering re-entry if it hadn't improved dramatically?

To be fair, that’s true of many languages and programming domains. The web, in particular, is one where you have to keep pace or end up out of the field.

Java and C# are a couple other popular languages where the same is also true.

Most likely this can be said about a lot of languages, most languages are being maintained and improved. I am an hired expert in Java and I needed to explain some new languages features to some colleagues that have been introduced recently, I only mention them if they actually improve readability though. I think PHP might be slightly different than other languages as a huge amount of people use this to create their first website as a hobby.

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 work on projects from PHP 5.6-8.4 and I can't say it feels that different. It's mostly just type differences.

But PHP 5 was released 21 years ago and is unsupported. Companies using it are putting their customers at risk.

I used laracasts.com plus AI code assistants to bring myself back up to speed pretty quickly.

You can still write php 5-esque slop and have it run... mostly (some particulars like the half dozen ways of interpolating a variable into a string have been paired down, some extensions left in the dustbin, but the fundamental "shit out a script and run it" capability still remains doable).

non of the "modern" things are particularly taxing to teach someone with more than two braincells. If they don't understand them then they haven't kept up with ANY programming trends in the past decade and are best placed infront of the TV with an iPad than left to mess with the possible critical infrastructure of a business.

PHP has no generics? I read somewhere that is was "too hard" to get right in PHP land, mostly because of how primitive the typesystem is.

Modern PHP is a damn fine, fast language. I wrote production PHP from 2021 to 2023. The problem with PHP wasn't the language or the ecosystem (PHP community packages are very solid in my experience), it's the existing PHP code you'll work with and the people that hire for PHP.

My salary literally doubled within two years of getting a gig that wasn't PHP. If you see a listing for PHP dev work, there's a good chance it's notably lower salary. There are still solid gigs for it, but I swear they lean lower.

The other problem is the existing codebases. There is some awful legacy PHP 4 era code. There are also a lot of practices that old PHP had that are just awful to work with, and there's a bit of variety in there. So many bad data access patterns out there. Many of old PHP codebases have their own spin on that kind of thing.

I understand this isn't actually due to the language, but there is a real correlation (in my experience) between old bad code and it being in PHP. Which is totally fair because it was a good tool to reach for to "get shit done (r)" and that code was successful enough to have to continue to live.

Modern PHP has, thanks to the core language and the big frameworks, made it wonderful. I lead a big push to go from PHP 5.8 to PHP 8.1 at the time at my last company. It was wonderful. The quality of the code we were enabled to write was huge.

If I was starting a new project today, I probably wouldn't reach for PHP, but I'd gladly join in on a modern (last ten years) Laravel project.

PHP is a very pleasant and straight-forward language to work with. I enjoyed my time working with it, though I did also see quite a lot of very poor code.

I think the danger with PHP is more its ability to easily cause *very bad things*.

This would partially be poor training (my University literally taught PHP with SQL-injectable examples), and I think the language itself making it very easy, such that less-experienced developers using it - most of them, early on - don't realise what's wrong until it's gone wrong.

With PHP being such an early tool online, and the above properties existing, it earned a reputation for being insecure and bad.

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...

I’ve made my living amd career off of PHP and I enjoy its modernization.

Coding in PHP can be a lot like playing the guitar or writing poetry: many people can do it, but it’s easy to do very badly.

https://github.com/AzuraCast/AzuraCast

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

> A lot of people are too proud to be associated with PHP.

How so?

> My favourite PHP product at the moment is BookStack (https://www.bookstackapp.com/), a really good wiki.

Another wiki that uses php is Wikipedia.

People like to shit on php but it powers some of the largest sites in the world.

At the end of the day, programming language doesn't matter much. You can be a good programmer in any language and a bad programmer in any language.

A lot of C# and Java code is oriented towards web backends, too. Which are quite big and complex. So it seems natural that languages in the same design space (trad OO) converge on similar features. I think the only exception these days is Go.

I think these days you could change "You can write Fortran in any language" to "You can structure your code like Spring in any language"…

The web is not getting any simpler.

Obviously you haven't heard of NativePhp :)

Still, even if it was "just" the web, why wouldn't it evolve? It's a great language, with a big user base, and there's always room for improvements and to increase the developer experience

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 unary functions, so higher arity functions must be wrapped in an arrow function. It's a mess and more bug prone than just nesting the functions.

Nice additions, but haven't really missed them a lot.

Most of the time if I want the first or last element I don't care about the array itself so array_shift and array_pop work just fine.

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.

Parse_url isn't standards compliant, often fails with relative url's and most importantly only parses urls, not uris (with the exception of file://). I also find it's syntax clunkier than the new uri(), but that's just personal preference.

The pipe operator is indeed just syntactical sugar (and the article links to another article specifically about it which does cover the case of temporary variables), but with the coming partial function application feature it (in my opinion) will make easier to read/reason chains of code than temporary variables or nested function calls.

> i dont see it being a pick for greenfield projects in 2025

You don't see it because you're not looking. There are many Laravel jobs in my area. If you think that is only for Legacy projects, might be mistaken.

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.

The three dots in trim(...) make a callable out of a function, that was already in, so seem best to re-use that syntax, at least for now. [1]

As for the partial function application, there is already an RFC to add that, but it's not decided on as of now. [2]

1: https://www.php.net/manual/en/functions.first_class_callable...

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

Your second option was rejected years ago I believe. The pipes were designed to work alongside this rfc that was supposed to be in this new version (8.5) but due to time constraints it had to be delayed and it’s currently being voted https://wiki.php.net/rfc/partial_function_application_v2

That example in article is straight up terrible. The Java version would be:

  var input = "Some kind of string.";  
  var output = Optional.of(input)
    .map(i -> i.trim())
    .map(i -> i.replace(' ', '-'))
    .map(i -> i.replaceAll("[./…]", ""))
    .map(i -> i.toLowerCase())
    .get();

  var input = "Some kind of string.";        
  var output = input.trim()
    .replace(' ', '-')
    .replaceAll("[./…]", "")
    .toLowerCase();

Counterpoint (from the same website): https://stitcher.io/blog/evolution-of-a-php-object

PHP 8.2 has this:

``` readonly class BlogData

{

    public function __construct(

        public string $title,

        public State $state,

        public ?DateTimeImmutable $publishedAt = null,

    ) {}

```

Whereas in php 5.6, to accomplish the same you need all this:

``` class BlogData { /* @var string / private $title;

    /** @var State */
    private $state;
    
    /** @var \DateTimeImmutable|null */
    private $publishedAt;
   
   /**
    * @param string $title 
    * @param State $state 
    * @param \DateTimeImmutable|null $publishedAt 
    */
    public function __construct(
        $title,
        $state,
        $publishedAt = null
    ) {
        $this->title = $title;
        $this->state = $state;
        $this->publishedAt = $publishedAt;
    }
    
    /**
     * @return string 
     */
    public function getTitle()
    {
        return $this->title;    
    }
    
    /**
     * @return State 
     */
    public function getState() 
    {
        return $this->state;    
    }
    
    /**
     * @return \DateTimeImmutable|null 
     */
    public function getPublishedAt() 
    {
        return $this->publishedAt;    
    }

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.

Can you share an example of what you're talking about in PHP 8.5? On the linked web page, the only code pattern that looks remotely complicated to me is the following:

    #[SkipDiscovery(static function (Container $container): bool {
        return ! $container->get(Application::class) instanceof ConsoleApplication;
    })]
    final class BlogPostEventHandlers
    { /\* … \*/ }

It's somewhat comforting to read my insecurities shared by others in this thread

Which parts of PHP have become harder to read?

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".

php has kept around a lot of functionality that can be misused, but PDO has had parameterization since forever and is the go to method if you want to connect to a database. Beyond that though, most PHP projects at this point are likely using a query builder/orm like eloquent.

So I guess it depends on what you mean by unhelpful. PHP as a language makes it pretty easy to do bad stuff. PHP as a community makes it easy to Do The Right Thing.

Prepared statements have been available in PHP for over 20 years, when it deprecated the old mysql libraries. They were removed entirely in PHP 7.

And let's be real - most handwritten SQL code in existence in most languages just builds queries from concatenated strings, even when more secure options exist. A lot of code doesn't even bother to escape anything. That's not a language problem so much as a developer laziness and assumption that "simplicity always equals correctness and frameworks are always wrong" problem.

You use PDO and prepared statements. Although realistically, you are going to be using a framework and some kind of Active Record pattern.

SQL named parameters was a feature introduced into PHP on 24th Nov 2005, with the release of PHP 5.1.0.

the MySQL extension was dropped in PHP 7.0.

You probably know about https://openswoole.com right?

I remember the discussions at the time about which filename extension to use - and I can not believe that .php3 won. I think that I was the first to bring up the subject for PHP 4, to use .php again and not include the version number.

Yes, see: https://news.ycombinator.com/item?id=39989663

---

Books:

* PHP & MySQL: Novice to Ninja by Tom Butler

* PHP 8 - Quick Scripting Reference by Mikael Olsson

* PHP 8 Objects, Patterns, and Practice by Matt Zandstra

* Programming PHP (2020) by Kevin Tatroe and Peter MacIntyre

I personally found them to be really good. I learned a lot from the first book especially.

You can find the code from the first book here: https://github.com/spbooks/phpmysql7

I hope this helps.

https://phptherightway.com/ Is a good place to start

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

What do you mean developers should deal with functions like those? They're used when necessary, yes, just like any function. And no IDE is required. I'm really puzzled.

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)

I would love that. But yeah, it would probably kill PHP because it would break all code.

Maybe https://getrector.com could auto-fix 99% of code but it would still be very hard to get adoption.

Without specifics it's hard to understand what kind of difficulties you had.

But PHP is still so strong because it offers much more than "easy hosting".

What I personaly love most is the instant save file->see results feedback loop. There's no perceptible compilation step. Meanwhile my Java project takes a minute to compile.

Also the shared-nothing model by default is powerful and rare.

Laravel is probably the most well documented frameworks even comparing frameworks from other languages. And symfony, also a PHP framework, is not far from that.

When you say "SSL" I can only think your reasoning is based on outdated information since no one calls it SSL anymore. It's TLS for some years now. And I have been connecting to databases using PHP TLS/SSL since version 5. For almost a decade now.