PHP Redux
Pardon the light (i.e., mostly non-existent) blogging for this last half of December.
I wasn’t quite expecting the “PHP is not an acceptable COBOL” post to be picked up the way it was. It circulated parts of the PHP community and, apparently, parts of the .NET community.
Most of the comments were interesting and, even when not agreeing with my admittedly dismal conclusion, thoughtful. Most, but not all. Helpful hint: if you call someone a “fanboy,” you are pretty much saying, “I have no substantive rebuttal, I’m just upset that you don’t like what I do.” Given that I wasn’t really advocating for any one specific language over PHP, it’s hard to figure out just what I’m supposedly a fanboy of. Python is my favorite scripting language, but Perl and Ruby are excellent languages, too, and there’s a host of others. Am I an “anything but PHP fanboy?” Kind of weak sauce.
Phil Sturgeon, a CodeIgniter developer, and Dan Horrigan, the lead developer of FuelPHP, both chimed in, with Horrigan correctly noting in comments that PHP is faster than both Ruby and Python1 and Sturgeon tweeting that my take was “absolute drivel.”
Well, Phil, thanks for the insight. Which part was drivel? Maybe when I wrote:
Over time, PHP has suffered everything from security failures to bad design decisions. Some of these problems were avoidable, but others weren’t. […] If asked what the problem [with PHP] is today, I would say, “no design and no plan.”
Oh, wait, that wasn’t me. That was developer Gwynne Raskind on an article on the “PHP Advent 2011” site entitled “Cracks in the Foundation” in which Raskind makes some of the same points I do, but comes to a more optimistic conclusion about PHP 5.4’s prospects. Fair enough, but I don’t seem to see Sturgeon railing against that. The “drivel” is stuff that’s fairly well-known in the PHP world. Raskind is less curmudgeonly, sure, but also gets into more serious issues I didn’t even touch on—how PHP will occasionally change the behavior of a widely used function and will vastly underestimate the consequences for backward compatibility in part because PHP’s own unit tests suck.
And no, I’m not overstating that. PHP 5.3.7 shipped with a horrible bug in the MD5 crypt() function—if you executed it with a “salt” parameter, which you always should, then instead of returning the hash, crypt() would return just the salt.2 Surprise, everybody’s encrypted password might as well be plaintext. This absolutely should have been caught by a unit test. If this doesn’t give you just a wee bit of pause before denouncing my cranky criticisms of PHP’s design, I don’t know what will.
Did Raskind convince me that going forward, PHP will fix its problems? No, but it’s reassuring that they’re at least aware of them. There are changes I’d like to see in the language itself, but hell, the new short array syntax in 5.4 will be fantastic—even though in typical PHP style, they seem to be ignoring established convention for no clear reason.3
Lastly, to the ASP.NET folks—and Java folks—while I am implicitly ignoring you, it’s in part because I simply don’t work with those technologies (especially the Windows-only ones), and in part because the kind of work being done in those languages tends toward an enterprise focus. This isn’t a comment on how good they are, and of course, there are examples of non-enterprise use of both—StackOverflow being a highly visible ASP.NET site, and Apple’s online store system being a highly visible Java—well, WebObjects—site.
And to the commenter who asserted that PHP is replacing Java in big enterprises: keep repeating that wish loudly enough and long enough, and eventually James Gosling will appear to you and kick your misinformed ass.
-
This is, of course, with the caveats that all benchmarks are flawed to begin with, and that even in otherwise identical environments, the difference between (say) PHP 5.2 and 5.3 or Python 2.6 and 2.7 might prove noticeable. PHP also has a lot of “accelerators” available to it, but c’mon: does anyone disagree that having to make sure your PHP interpreter is compiled with the
go-fasteroption (or whatever) is suboptimal? ↩ -
Although you shouldn’t be using MD5 for passwords, salted, peppered or otherwise. Use bcrypt. ↩
-
Javascript, which most PHP developers also know, uses
{key: value}for this, as does Python. Perl and Ruby use{key => value}. They all use braces. So PHP is going with[key => value]because, hey, PHP! ↩
