Why is PHP hated by so many developers?

 

Anders Kaseorg, MIT 2008, Co-Founder of Ksplice, Inc.

 

There are many good reasons to hate PHP, and they run way deeper than some inconsistently named functions with misordered parameters. Learning PHP will actually transform you into a worse programmer, and writing in PHP will leave behind a mess that’s a costly nightmare to maintain and clean up after. Here are my top four reasons.

  1. PHP encourages an insecure programming style by design. Its very syntax encourages you to splice unescaped values directly into database queries and HTML output without thinking twice, leading to SQL injection and cross-site scripting vulnerabilities. To write any PHP code that isn’t riddled with these security holes, you have to actively work against this by carefully sprinkling your code with calls to functions with long names like htmlspecialchars() and  mysql_real_escape_string() (that’s right, make sure you use the real one!*). If you want any protection from cross-site request forgery attacks, you need to go implement it yourself. This is all basic stuff that any decent web framework for real programming languages will take care of for you automatically, but most PHP developers are too lazy to do it by hand (or don’t even understand that they need to), and even the best ones slip up occasionally. That’s why web applications written in PHP consistently have terrible security track records.

  2. The language is a minefield of hidden security problems. Even something as simple as
1
2
3
4
5
6
7
 
<?php
if (strcmp($_POST['password'], 'sekret') == 0) {
    echo "Welcome, authorized user!\n";
} else {
    echo "Go away, imposter.\n";
}
?>


is vulnerable to attack:

1
2
3
4
5
6
 
$ curl -d password=sekret http://andersk.scripts.mit.edu/strcmp.php
Welcome, authorized user!
$ curl -d password=wrong http://andersk.scripts.mit.edu/strcmp.php
Go away, imposter.
$ curl -d password[]=wrong http://andersk.scripts.mit.edu/strcmp.php
Welcome, authorized user!


(This example was not artificially constructed to demonstrate a potential security problem; it came from a real-world website breakin! This vulnerability was silently introduced by a change to strcmp in PHP 5.3 and later that wasn’t even mentioned in the release announcement or the migration guide.)

  1. The documentation is full of harmful advice. Even the sample code from the official FAQ on how to avoid cross-site scripting attacks is vulnerable to cross-site scripting attacks! I couldn’t make this up if I tried:
1
2
3
 
<?php
    echo "<input type='hidden' value='" . htmlspecialchars($data) . "' />\n";
?>

(htmlspecialchars does not escape single quotes!)

  1. PHP references are brain-damagingly wrong. I mean that literally—I know from personal experience that PHP references will damage your brain in ways that will make it harder for you to learn how references and pointers work in real programming languages.


Update, two years later: It’s telling that the world’s largest PHP shop, Facebook, has invested millions of dollars of engineering effort into developing a new language to replace PHP and migrating nearly their entire codebase away from PHP. I’m only amazed that it didn’t happen sooner.

For hundreds of other reasons, see

PHP is not merely awkward to use, or ill-suited for what I want, or suboptimal, or against my religion. … Virtually every feature in PHP is broken somehow. The language, the framework, the ecosystem, are all just bad. And I can’t even point out any single damning thing, because the damage is so systemic. … But I’ve got to get this out of my system. So here goes, one last try.

These are things in PHP which make me sad. They are real, objective issues which I have personally encountered in my normal day-to-day activites.

What’s depressing is not that PHP is horribly designed. Does anyone even dispute that PHP is the worst designed mainstream “language” to blight our craft in decades? What’s truly depressing is that so little has changed.


(* The PHP documentation, starting a year after I first wrote this answer, finally discourages new use of the original mysql extension in favor of the newer mysqli and PDO_MySQL extensions, which provide slightly better solutions to the SQL injection problem, if you’re lucky enough to have a PHP installation that has them enabled and a code base that uses them.)

(photo source)