Hacker News Reader

Comment by ipaddr | Hacker News Reader

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.

View on HN

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.

[1] https://go.dev/doc/go1compat

Like everything... It depends.

Just use rector

https://github.com/rectorphp/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.

I use it all the time and it works great. You need to know what you're doing.

So again, you seem to be confirming my point that it’s not fool proof.

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.

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

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.

Surprised to see Go in your list though.

Reply on news.ycombinator.com