Slashdot Mirror
As PHP 5.6, Still Used By a Large Number of Websites, Approaches Its End of Life Deadline, Some Worry About the Consequences (linkedin.com)
An anonymous reader writes: I know PHP isn't to some devs liking, but chances are you know people who work with PHP or have sites that are built with it. PHP 5.6 and 7.0 are shortly coming to the end of the support period for security patches, so what plans have you made to migrate code and sites to newer platforms? With apparently huge numbers (80%) of sites still running PHP 5.6, there appears to be little industry acknowledgement of the issue. Is there a ticking PHP Time Bomb waiting to go off?
The current RedHat 7 ships PHP5.4 (or lower) by default. Adding 5.6 means adding a non-standard repo and thus tainting your update environment. Can be done but not classy.
Having said that, I run a small ISP with many tiny NGOs as customers. All these sites were developed for PHP5.2 or something by "Bob" who left and nobody has the money or expertise to update the site to PHP5.6 or higher. If I force an upgrade I effectively kill over 300 websites that are pretty much running fine, despite the vulnerabilities puslished. Remember that most of these customers have ever even heard of PHP or what it is supposed to be doing, and they care even less as they are not IT people.
If an experiment works, something has gone wrong.
Sure, let me just go back to the hundreds of small businesses we've built websites for over the past 10 years and tell them their sites need to be "simply rebuilt". I promise you that 95% of them will see no problem with leaving their PHP 5.6, 5.4, 5.2, etc... websites alone because "they still work fine". Why would they pay us money to rebuild them?
Maybe, but the site owners know how to use that admin interface, and getting them to that point was like pulling teeth. Now you want to train them on a brand new interface? Good luck.
I'm not saying this guy doesn't have some points, just that he doesn't seem to live in the real world.
Frameworks, languages should always provide a clear migration path and never jump major versions. Python, Zope, PHP, and many more learned that lesson in a hard way.
That's dumb. Rewriting or porting software introduces bugs and security flaws. Good developers are good in any language. Hire good developers. Any developer who wants to rewrite everything when they come in isn't a good developer.
I would expect a simple update guide with breaking changes and simple resolutions.
Expected it, got it. Google Search for php 7.0 breaking changes returned this section of the official migration guide as the first result.
Such as?
PHP is still widely used because it's fast (performing) and fast to develop in, free, well-documented and has a huge framework library and developer base to draw on.
That doesn't make it a good language, but it does make it the one to beat. I have yet to see anything that can do what PHP can do. All the "better" tools are slower, take twice the development time, lack turnkey solutions, or are obscure enough that you need to do a months-long search to put together a (high-priced) development team.
That's true, unless the code uses the (LONG deprecated) mysql_* functions. Though even that is actually trivial to fix, since PHP7 supports built-in function overloading, and since good code will abstract database calls anyway, even switching to one of the newer DB methods should be pretty straightforward.
I maintain code that was actually written for PHP3/4. Migrating to PHP5 was frustrating, mostly because some of the the breaking changes involved REALLY basic stuff (they broke array indexing!), and weren't rolled out with the first version of PHP5, but came out in dribs and drabs in the point releases. Migrating to PHP7 is really not that bad by comparison, and PHP7 fixes most of the really bad warts in the language.
Granted this code was originally written almost exclusively by me, and I was/am a Perl/C programmer so the code looks more like C-style Perl than most PHP code.
PHP3 was *nasty* and I went into the project kicking and screaming, but I was part of a team that outvoted me. I wanted to write the thing in Perl. Almost 20 years later, the code still works, is maintainable/customizable, and the language itself is much less nasty than it was then.
While I agree with you, it's also clear you have not written any frameworks. Or at least none that had to survive multiple versions. It's hard.
There are three kinds of falsehood: the first is a 'fib,' the second is a downright lie, and the third is statistics.
You don't allow for the possibility that a PHP developer is talented, works with talented people, and are generally happy writing good code in PHP.
Thank you, yes, that's much closer to what I was saying.
When I hire a dev, I'm looking for someone with good judgement. If I come across a candidate that was actively using PHP at their last job, then I am most definitely going to dig in to make sure that that candidate has a good grasp of its flaws and a good explanation for why it continued to be used anyway.
If they can't do a solid job of explaining that, then no, they probably aren't a very good dev.
It's not that I doubt that somewhere, somehow there exists a good dev who is using PHP for a good reason, it's just that it's typically a strong indicator of not-so-good devs. Even before the interview stage, when I'm looking at a resume, if PHP is highlighted or emphasized, I almost always just move to the next one in the stack - it's possible that I'm missing a great candidate but far more likely that I'm not.
> Why would you be comparing differently typed items anyway?
You _never_ make typos in code?
You _never_ compare the wrong types by accident?
Good programming embraces Fail Fast. One of the advantages of static type checking is that you know instantly if what you are doing is nonsense.
PHP and JavaScript are crap because they embrace "Fail Whenever" -- a HORRIBLE practice for scalability, correctness, and robustness.