PhpRiot
News Archive
PhpRiot Newsletter
Your Email Address:

More information

How PHP is Broken and How It Can Be Fixed

Note: This article was originally published at Planet PHP on 1 September 2011.
Planet PHP

PHP's development process has been broken for a long time, and the failures of that process have swelled since the first ripples began to appear many years ago. The process didn't necessarily take a downward turn at any point; rather, it seems there was never really a sufficient or sustainable workflow from the start. This is no surprise given the very fluid history of PHP though, and the lack of any sustainable processes may have even been one of the key things that allowed PHP to evolve so quickly into one of the most used programming languages in the world. But that early success doesn't make the PHP development process any less broken.

Before I continue, I want to be perfectly clear: There are many reasons that people bring up for disliking PHP, and I will not be entertaining most of them here. If you do not like PHP because of things such as an inconsistent API, seemingly half-hearted additions (e.g. object model or namespace support), or any of the other language-specific beefs that spring up whenever someone leaps on their e-soapbox, please move along. This isn't the post for you. All things considered, I like PHP, and I think it is the best option for developing most of the applications that we see on the web today.

How PHP is Broken

The serious problems - the ones that actually have long-term consequences, stem from the development process.

Through most of PHP's 16 year lifespan, it had a completely arbitrary release process. When core devs felt like they wanted to push a release, they got together, patched up some of the code that had been contributed for the many weeks, months, or years since the previous release, and tossed it out into the wild. The consequences of this still linger throughout the community (and the entire web) today: without any clear release planning, it was more efficient for organizations to leave their PHP versions un-upgraded than it was to incrementally upgrade their versions in a timely manner.

In addition to no sensible release cycle, the way new features were discussed, approved, or rejected was largely informal, difficult to follow, and without any sufficient time constraints. It was hard for anyone that didn't follow the mailing list and wiki word for word, every day to have much of any idea about what was going on.

PHP's test coverage is not good. To make matters worse, passing the existing unit tests is not a requirement for acceptance in the core. Why even write the unit tests if someone can simply choose to ignore them when merging in their code? This has to be the type of thing that Sebastian Bergmann has nightmares about.

Don't worry though, just because it is acceptable to commit code that breaks the unit tests doesn't mean that this will actually affect the stability of the releases, right? I mean, the stable releases of PHP at least pass the tests that they do have, right? Wrong. Surely you've all heard about the fiasco that was the PHP 5.3.7 release, but just in case you need a quick refresher:

Eleven days ago, PHP 5.3.7 was released as stable. One day prior to the release, a major bug was reported that identified an issue where using crypt() with md5 hashes was broken so badly that it was completely unusable across all platforms. Four days after the stable release, PHP.net finally got around to officially announcing the problem and a day after that they released PHP 5.3.8 with a fix. To their credit, many of the core devs did get the word out about this issue very quickly, but why it took four days to officially acknowledge the problem is completely beyond me.

The delay in an official acknowledgement of this issue is certainly disturbing, but here's the kicker: Even at only 70% code coverage, this bug was identified by the unit tests. The tests that were in place to make sure that bugs like this couldn't happen did their jobs - they failed when they were suppose to fail. Without any automatic testing constraints in place for packaging releases, those failures went unnoticed, and a "stable" release of PHP with an application-breaking bug was released to the masses. For this to happen, one of two things had to occur: someone released a stable version without running tests on newly added code, or, more likely, someone didn't notice that there was a really important test failing because PHP 5.3 has 192 failing unit tests

Truncated by Planet PHP, read more at the original (another 4456 bytes)