Matthew Mullenweg isn’t terribly impressed with GoPHP5 or the php-internals people on the whole topic of dropping PHP4 and moving on to PHP5 and PHP6. Now, given that Matt’s the guy who founded WordPress, I reckon his opinion’s worth listening to, and given how much time I spend using vim, LaTeX and mutt, I know where he’s coming from; but he’s wrong in this instance, or at least, he’s looking at it the wrong way.
See, the difference between PHP4 and apps like LaTeX or vim is that, well, LaTeX is done. As in, it works, it’s bug-free (no, seriously, it’s as bug-free as it gets outside NASA, and a bit more so on occasion), and it does everything that its users require it to do, and well. PHP4… doesn’t. Yes, you can build apps with it, and yes, many great ones have been written. Cool. But it’s object model is fundamentally … not an object model. And it’s slower than PHP5. And if PHP itself is to survive as a language in what is a competitive space, it has a lot of work that needs doing to it. Fundamentally, it’s not done yet. It’s getting better – but to do that, it has to change, and if that means PHP4 is being left behind, I don’t think that’s worth any more tears than, say, Debian 3.0 being left behind when Debian 4.0 replaces Debian 3.1 as the stable release. It’s just how this stuff works.
Vidyut on the other hand, agrees with Matt, but more from the point of view of the end users, rather than the developers. And that’s not really all that on point, to be honest. If the developer does his or her job well, then the end user should never know what the engine is doing in the background – which, ironically enough, is his first reason as to why the PHP4->PHP5 move is a bad idea. I don’t quite get that reasoning myself. As to saying that the code clean-up that PHP5 permits is completely pointless… well, that’s just plain silly really. I mean, you can’t say that the end users shouldn’t know what the engine is doing on one hand, and on the other say that they think your code is fast and clean.
Maybe it’s a confusion over who the end users are. I mean, from the php-internals point of view, app developers are the end user; and from the developer’s point of view, the end users are, well, users.
This whole idea, though, of forking off PHP5 and leaving PHP4 alone… well, in effect, that’s what’s being done. PHP4 is being dropped. So, if you want to maintain it, do what the Joomla core team did, take a snapshot of the code and start with your maintenance and release cycles and keep PHP4 going.
I don’t think it’s a good idea though. I’ve coded in PHP5 and in PHP4, and I’ll never code in PHP4 again if I have any degree of choice in the matter. It’s too difficult to properly implement and maintain designs in it when the number of developers rises above one!
Further to this, I just got burned purchasing software that had system requirements of “PHP 4.1 and later” and “MySQL 4.1 and later”, I purchased it, and was then told “don’t be dumb of course we didn’t mean MySQL 5 and PHP5!! If we’d meant PHP 5 we’d have put it in the requirements” my argument was that PHP5 has now been around for 3 years and I had no reason to believe that it wasn’t a part of the “later” specification (as I would have, for instance were I assuming PHP6 was supported. Anyway the long and short of it is I’m about £250 out of pocket with no likelihood of getting a refund. Moreover the software company has done nothing at all to modify or clarify their specs, which leads me to believe they make good money from this. C’est la vie!!. The moral of this story, PHP5 is not later than PHP4 and apparently no one supports it or uses it (except me!!)
In the system I was tetnsig on I was using the IN() operator with a list of primary key values, (the PK is just an autoincrement column), so there was an index. The table was ~160k rows, and there was a join of some sort involved, (although the where condition didn’t use anything from the joins, it only had the IN(pk list)). I had an unused column available so I just set it to greater than 0 on the rows I wanted and changed my WHERE to WHERE unusedcol > 0. That got me more speed, strangely enough.As you say, benchmarking, (or at least some real-world tetnsig), is the way to go. You never know when something weird’s going to happen in the database engine, and every production environment is different. I just thought I would share my experience, since it’s not what would be expected, (if it was expected, I would never have written the query with an IN() in the first place!).