Honestly, the development of the PHP core has always been rather amateur. From historically just adding features whenever to know adding hundreds of breaking changes per minor release. This results in a terrible codebase and a language where upgrading minor versions is so painful and costly for some firms they end up stuck on old version.
The last part makes the fact their could be massive security holes like RCE in the core language very worrying.
Historically they have been one of the languages that added very few breaking changes and were criticized for that. You can't have it both ways.
Going from php 4 to php 8 isn't even that painful and there are twenty years between. It's the one language where what you wrote 20 years ago probably still works today.
Upgrading a php application is one of the least expensive and uneventful things you can do. Try upgrading that java swing application or that react app that's 15 months old. Go, haskell, vue, python 2 to 3 are more difficult because of syntax changes where in php you have some breaking changes like globals being removed or ereg removal or mysql_ being removed. The changes were small like using mysqli instead of mysql or using preg instead of ereg.
Somewhat contrary to my own comment below, migrating PHP upwards can be painful, but some of that stems from who's involved. I'm brought in on PHP upgrade projects, and often the code is 10+ years old, and no one who wrote it is still around. There's typically no documentation, no tests, and little historical knowledge.
Now... that's also a problem in other languages too, but I've found it less so with something like... older Java. Because there are some things that are completely gone from earlier PHP, if people relied on those bits 15 years ago, there's potentially a lot of code touching that needs to happen.
My experience is there's less deprecation of language features in older languages (mostly thinking of Java). There were perhaps less 'wonky' ways of doing dynamic Java stuff in 2006, so 2006 Java will still work today. 2006 PHP can work today (see comments below), but the more 'advanced' your PHP was the more at-risk it will be when trying to upgrade to, say, PHP 8.x.
The other big thing, though, is frameworks. The more you tied your code to, say, ZF1, the bigger an upgrade effort will be (sometimes far bigger than expected). I've been hit by this a couple times in the last few years.
My complaint was adding lots of breaking changes to minor version upgrades. The fact, that historically they didn’t do breaking changes in major version upgrades does not excuse going against industry standards.
There are literally companies stuck on PHP 7 because going to 8 is too painful. And honestly with my decade of experience your claim that going from 4 to 8 isn’t that painful sounds like nonsense and something you haven’t done. And the claim that php 4 code will work on php 8 is 100% nonsense. The syntax for how classes were defined in 4 is not supported in 8.
I’ve upgraded the code to the major versions of other languages without hassle. But they generally had fewer breaking changes in their major versions when I upgraded to Vue3 which was super painless.
And can you point to a minor upgrade where Go changed the syntax to the point the old one no longer works? With Go normally it's the tooling that changes. I can't remember the syntax changing on me. Especially since they have a Compatability Promise[1] it seems weird.
> There are literally companies stuck on PHP 7 because going to 8 is too painful.
Usually due to frameworks. Those tend to do play fast and loose with language constructs so small changes can make them not work anymore. And as those same framework will also break a lot more things between version, you cannot easily upgrade them, so you cannot upgrade your php version.
Currently maintaining an internal symfony 1 website so I know the pain. At least the documentation of old symfony is still available unlike many more modern frameworks.
Our best engineer spent 2 weeks full time updating our codebase from 7 to 8 using rector (the project was already running PHP 7 but still had a lot of deprecated code from the PHP 5 era which didn't work on PHP 8). That would be eternity without Rector.
I've previously used that to do something. Fell flat on its face. But the fact they literally had to create a tool to solve this problem confirms my point.
You are right, going from 4 to 8 is a huge challenge.
Minor point: classes are using the same syntax but you are right they typically won't work because the constructor have changed, in PHP4 it was a function named the same as the class, in PHP5 and on it's __construct, the PHP4 version was deprecated in PHP 7 and removed in PHP 8.0.
create_function is just gone. So is each(). Oh and HTTP_RAW_POST_DATA. The list is long.
If you have used == and in PHP4 we did that, come on, don't be holier than holy and claim you only used === in PHP4 then PHP8 will have some surprises for you.
In my experience rector became usable last year-ish, if you tried before, give it another whirl.
There’s a system that I started working on, in 2008, when a lot of hosting outfits were still running PHP 4. It’s still running now, but I think one of the current maintainers rewrote a lot of it with Laravel, recently.
I know that they were still using the old code, just a year or so ago, on PHP 8.
I had code I wrote for someone in 2002 (php4) still running in 2017 (php 5.x). It broke trying to go to 7, and it was a small area that broke. It was core, so broke everything, but it had to do with re-assigning of $this at runtime. I think in 5 it was complaining about it as a warning, but no one was looking. Had I/we been stricter about the use of $this back in 2002, that code might still be running today. Doesn't mean it should or wouldn't be faster if rewritten with newer language features, but ... it had a good run for 15 years.
EDIT: Was reminded of another site started in 2000 (start of PHP4) that is still running. I can only see the login page now, but I see the login page is still displaying a particular URL structure that was/is slightly uncommon. If they kept that but rewrote the entire thing internally... that would be odd, because it would be easier to rewrite the whole thing. I've no doubt they've upgraded some internal parts, if only to accomodate new business needs over the past 20+ years (I stopped working with this project in 2003?) but it's still up and running.
> From historically just adding features whenever to know adding hundreds of breaking changes per minor release.
Should be noted that it stopped being the case close to a decade ago now. Since PHP 8 things have changed a lot and it's a significantly better platform, both in terms of usage and the people behind it.
PHP spent a long time running on fumes with little backing. It's now got huge financial backing from Jetbrains, Wordpress Symfony, Laravel etc and theres now people paid to work on it, which has dramaticly improved the quality and quantity of improvements, which are mostly focused around performance and bug fixes.
The performance gains arent just figures on paper either. There was a real world improvement of around 12% on PHP 8.3 alone.
I think the fact Facebook decided to just fork that language instead of improving it shows how bad the core development was. The internals newsletter was just brutal. I remember reading a thread from a Facebook dev asking who quietly just reverted his commit. No discussion, no nothing, the code was just reverted if someone didn't like it.
I really think that was a major misstep by the project.
> I really think that was a major misstep by the project.
Oh, yeah.
As someone who has written and maintained a lot of "infrastructure-level" stuff, I have come to learn that releasing a project that serves users, or is infrastructure for other projects, is like having children.
Making them is fun. Releasing them, is a pain, but, once they are out there, it is my Responsibility to support them, and accept that they have their own agency.
I can't just go in and pretend that I'm Lord Farquaad, and treat the project as if it's my private fiefdom. It's now a public resource, and my decisions and actions affect a lot of others. I also tend to write software that supports folks with a rather ... pithy ... demeanor, so screwups can result in not-pleasant feedback.
That's a big reason why I don't mind that most of my public repos aren't popular.
Hack is only PHP in a very ship-of-theseus sense - it has PHP _vibes_ but they replaced the language, the runtime, the standard library, and all of the infrastructure
(and all of them much improved over PHP IMO - especially XHP [equivalent to JSX, where HTML is a first-class citizen in the language syntax])
> Should be noted that it stopped being the case close to a decade ago now. Since PHP 8 things have changed a lot and it's a significantly better platform, both in terms of usage and the people behind it.
The breaking changes section of UPGRADING file for PHP 8.4 is over 200 lines. For 8.3 it was over 100 lines.
And when it went to version 8, there was only 1 full-time developer working on it and as far as I know 0 part-time. The rest were volunteers doing it as a hobby. That full-time developer who was paid by Jetbrains decided he wanted to work on another project. This resulted in the next release being pretty much nothing. At which point, everyone realised this language went from funded to not funded and they created the PHP foundation.
I assume you're referring to what the upgrade guide refers to as "Backward Incompatible Changes". If so reading through the list I can't see a single one on there that has a major impact, in fact I'd wager that 99% of all 8.3 instances will have no issue upgrading to 8.4 as they are all very superficial changes to some very legacy areas of the language.
I'm also not seeing 200 on there, though you said "200 lines" are you talking about the length of the article, if so thats not really a helpful metric.
> I assume you're referring to what the upgrade guide refers to as "Backward Incompatible Changes". If so reading through the list I can't see a single one on there that has a major impact, in fact I'd wager that 99% of all 8.3 instances will have no issue upgrading to 8.4 as they are all very superficial changes to some very legacy areas of the language.
They changed error handling. That is a major impact. If things start throwing errors when they previously didn't it results in your app breaking because how you were handling errors is no longer applicable. Now you have third-party libraries, etc all breaking because the PHP core team can't be bothered to follow industry standards. And yes, SemVar is, at this point, the industry standard to the point people use 8.* in their composer require because they expect SemVar.
And changing error handling in very legacy areas of the code is the worst especially when there isn't even an RFC to say that they would be doing it. The fact it's legacy means people don't expect it to change.
> I'm also not seeing 200 on there, though you said "200 lines" are you talking about the length of the article, if so thats not really a helpful metric.
It's useful in giving an impression of the number of changes. Especially, when given an example of another release to see how they're increasing. And it's extremely useful when comparing to other languages where the breaking changes section either doesn't exist or it's extremely small. 200+ lines even with formatting and some lines taking two ends up with over 100 breaking changes.
I get it, you like PHP and you're protective over your tooling. I use PHP heavily, in fact, I'm building my business on top of it. But that does not remove my ability to look at how everything is compared to other languages and see there is a major problem. On Ubuntu, it has packages for each minor release whereas in Python it's just python3-*. Why? Because PHP's reputation for adding breaking changes whenever (despite the claim that they're really good at it) has been there for so long that even Linux distros know that people need to deal with that pain.
The problem with me being mainly a PHP developer is, I know all the problems. You can't BS me like you can devs who don't work with it so much.
