Do we really hate PHP? Nah. If we did, we wouldn't be running Drupal and WordPress and other frameworks at the astronomical clip we do. Nope, true PHP hate would mean switching to Java. But familiarity breeds contempt, and let's face it, what the PHP naysayers say about one of our favorite server-side scripting tool has some merit.
What follows are 12 gripes we have built up in our years of working with the language.
Switching gears is a headache
The most important challenge in creating PHP is remembering when you're typing HTML and when you're typing PHP code. Mixing them together is a big selling point for PHP but taking advantage of it can be a pain. You look at a file, and it looks like code. But wait, where's the perfunctory tag that shifts us from writing HTML to creating server instructions? It's like you've taken two files operating on two different layers and smooshed them together. You've got to mind those tags because the whole purpose is to merge code with markup. Except when it makes everything more confused.
The markup maze
Mixing server instructions with browser markup is a mistake. Over in Java land, the teams talk about strict adherence to the MVC paradigm. The model for the data goes in one file, the layout instructions that control the view go in a second set of files, and the logic that makes up the controller goes in a third. Keeping them separate keeps everything a bit more organized. But in PHP land, the bedrock design decision is that you're supposed to mix HTML markup with controller logic for the server. You can always separate them -- and many do -- but once you start doing that, you have to start asking yourself, "Why, again, are we using PHP?"
Inconsistent and idiosyncratic nomenclature
Does anyone know when we use underscores? The method base64_encode uses an underscore, but urlencode doesn't. The name php_uname has an underscore, but phpversion doesn't. Why? Did anyone think about this? Did anyone edit the API?
Meanwhile, function strcmp is case-sensitive, but strcasecmp is not. strpos is case-sensitive, but stripos is not. Does the letter i signify case-insensitivity or does the word case? Who can remember? You better.
Sorting hell
How many sort functions does the world really need? Java has one basic sort function and a simple interface for all objects. If you want another algorithm, you can add it, but most make do with the standard function. In PHP world, there's a long list of functions for sorting things: usort, sort, uksort, array_sort. (Note that only some use an underscore.) So start studying and get that cheat sheet ready.
Open source has its limits
PHP may be open source, but the good features like caching are commercial. This is just an expression of reality. Zend needs to make some money, and it supports the entire PHP world by selling the best versions to people who need it. Complaining about this is like complaining about gravity. There are just things about earth that suck. Just don't fool yourself into thinking that it's all one big open source commune.
Broken namespaces
Do you want to create your own functions? First decide whether you're going to use PHP 5.3 or later because that's when namespaces arrived. If you don't, make sure they don't collide with a library because in the old days, everything was global. And if you're going to be running PHP 5.3 and you want to use the namespaces, get used to the backslashes, one of the uglier punctuation marks ever invented.
Type safety is broken
Way broken. PHP programmers are fond of noting that this expression is true:
(string)"false" == (int)0
Notice this isn't one of those classic examples that some PHP fanboi will argue is really a side effect of a feature. After all, JavaScript has plenty of similar examples caused by its overeager type conversion. Nope. The line says that the thing on the left is a string and the thing on the right is an integer. But somehow they're all equal. It's enough to make you believe that everyone in the world could just get along in harmony if only the PHP designers were put in charge.
Too many options, too many redundancies
There are too ways to do too many things. End of line comments can be specified with either a number sign or a double slash. Both float and double mean the same thing. Simplicity is often tossed aside because people have added their own little features along the way. It's like design by committee, but the committee never met to iron out the differences.
Weird variable naming conventions
The dollar sign prefix is confusing. Perhaps it makes sense to force all variables to begin with a dollar sign because it makes inserting them into templates a bit simpler, but shouldn't the constants also start with a dollar sign?
CPU tug-o-war
There are numerical issues with big integers on 32-bit machines. They wrap around, but the 64-bit machines don't, meaning that code will run differently on different machines. You can test it on your desktop, and it will run just fine. But when you move to the server, it could do something entirely different. Then when you try to re-create the error on your desktop, you're out of luck. The only good news is that 32-bit machines may finally disappear.
SQL injections
It's not really fair to blame PHP for one of the biggest class of security holes. People slip weird SQL strings past other languages too. It's just that PHP makes it easy to suck data from a form and send it off to MySQL. Too easy. The average newbie could make the same mistake with any language, but PHP makes it far too simple.
Too many incompatible changes
There are big differences between versions. Compatibility isn't so simple. Many languages like Java or JavaScript have sacrificed fast evolution for backward compatibility. It's not uncommon for older code to run without a problem on newer machines. But not PHP. There are big differences between the various versions, and you better hope your server has the right version installed because you'll probably only notice it when weird errors start appearing. The first thing you look for when your server goes south is whether someone upgraded PHP.