Why PHP is obsolete

(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at: lawrence@krubner.com

I was a huge fan of PHP back in the year 2000. I started using it right before the official release of 4.0 in April of that year. At that time, if you wanted to build a website, the main alternatives were C, Java, Perl and ASP. My criticism of those 4 were:

1.) C — too complicated for a fast changing website. Compiling an app took time, compiling was slower back then, there were fewer Open Source tools, and proprietary tools were outside of my budget. Too verbose. Managing dependencies was a very complicated situation.

2.) Java — better than C, but still too verbose, and compiling took time, which made development slow when you were dealing with a rapidly evolving website. Managing dependencies was a very complicated situation.

3.) Perl — as good as PHP in most ways, except that it lack any kind of package manager. There were modules in CPAN that could do almost anything, but you had to download and install them. Managing dependencies was a very complicated situation.

4.) ASP — as good as PHP is most ways, except it was a Microsoft tool, and using it would have sucked me into the expensive world of Microsoft.

For 3 of these, I’ve written “Managing dependencies was a very complicated situation”. That was probably the key thing about PHP, at least for me. It had an all-in-one philosophy. At that time, there was nothing like modern package managers. Nowadays we are spoiled with awesome tools like Bundler for Ruby and (my favorite) Leiningen for Clojure. But there was none of that in 2000. “Package managers” at that time would have been a reference to Linux distros, which sort of introduced the idea. And even the Linux package managers have gotten better since 2000. PHP’s all-in-one philosophy solved the package management problem that existed at that time. But now that we have a wealth of great package managing tools, PHP’s greatest strength is rendered obsolete.

PHP had other strengths, of course. It was optimized for the web, but that hardly makes it unique nowadays. For those of us who were frightened of C, it gave us nice wrappers around C functions. But other languages make this even easier nowadays:

Julia’s only drawback at this point is the relative dearth of libraries — but the language makes it unusually easy to interface with existing C libraries. Unlike with native interfaces in other languages, you can call C code without writing a single line of C, and so I anticipate that Julia’s libraries will catch up quickly. From personal experience, I was able to access 5K lines of C code using about 150 lines of Julia — and no extra glue code in C.

These last few years I was hired by several corporations (Wine Spectator, Timeout) to work with their systems, most of which was PHP, and most using the Symfony framework. I have already written my criticisms of some the systems that I had to work with. I feel that the people who nowadays use PHP in corporate environments have forgotten why PHP first appealed to anyone. I can tell you what advantages PHP offered in 2000, but what does it offer today? It is slow, it is cumbersome, the systems have become very complex, the uncompiled nature of PHP has become a problem as people try to do more ambitious projects with it. If you build a CMS, and you have traffic that needs 100 webservers, then you need to deploy the whole CMS to each of the 100 webservers.

What is cutting edge in the world of PHP nowadays?

People are adding pthreads yet PHP lacks the tools to manage concurrency (for a point of contrast, check out Clojure).

Complicated code cache systems in Symfony. As in: “Note that there are two disadvantages when using a bootstrap file: the file needs to be regenerated whenever any of the original sources change (i.e. when you update the Symfony2 source or vendor libraries); when debugging, one will need to place break points inside the bootstrap file.”

Annotations added into the comments. Unlike the author, I think they are still a bad idea when added to the PHP language itself. If you need to model cross-cutting concerns, maybe you should switch to a language that handles cross-cutting concerns with grace, rather than use a language that bolts on annotations as a half-baked solution.

A backlog of fixes necessary to deal with a long history of inconsistent development.

Bloated memory management.

Ceremony oriented programming without the benefits of speed or compile-time checking (which are the normal benefits of ceremony). Back in 2000 one of the arguments for PHP was that it allowed us to escape the verbose ceremonies that were common in languages like Java. Do we really want PHP to end up looking like Java?

A love of complexity for the sake of complexity.

No management of configuration settings. This is similar to the lack of package managers that PHP used to suffer, relative to languages such Ruby or Python or Clojure, but here no work has been done to solve to the situation, rather, it is left to sysadmin tools such as Chef and Supervisor to solve the situation.

Invisible demon monkey patchers. Traits are a lot like monkey-patching in Ruby, but traits are even harder to track and debug.

Ambitions that outrun the language. As Fabien Potencier says, PHP has some great features. Which is odd. It’s like having a super-powered Ferrari engine in a rusty old Fiat body.

An endless assortment of convenience functions.

And, of course, there is the famous essay “PHP: a fractal of bad design“.

Where PHP has cool features (as with the Streams and Iterators that Fabien Potencier mentions) they tend to be bolted on to the language, rather than deeply integrated. One never gets the sense that there is any profound philosophy shaping PHP. Rather, we have Ramus Lerdorf saying stuff like:

We have things like protected properties. We have abstract methods. We have all this stuff that your computer science teacher told you you should be using. I don’t care about this crap at all.

As a point of comparison, Yukihiro Matsumoto describes Ruby this way:

For me the purpose of life is partly to have joy. Programmers often feel joy when they can concentrate on the creative side of programming, So Ruby is designed to make programmers happy. If you get your job done quickly and your job is fun, that’s good isn’t it? That’s the purpose of life, partly. Your life is better. I want to solve problems I meet in the daily life by using computers, so I need to write programs. By using Ruby, I want to concentrate the things I do, not the magical rules of the language, like starting with public void something something something to say, “print hello world.”

The lack of philosophical insights offered by the leaders of the PHP community tends to manifest in ugly ways, especially as a lack of guidance given to beginner programmers about how good code should be written in PHP.

In 2004, Ruby On Rails burst on to the scene, and promised to save us from the complexity of Java and the messiness of PHP. And it was a huge improvement at that time. It offered a structure and elegance that PHP could only dream about, during that time. But nowadays, even Rails is beginning to seem obsolete. Neither Ruby nor PHP are set up to deal with concurrency: they were both designed in the era when computers had just 1 CPU, and that CPU could be relied upon to get faster and faster every year. But the future of computing will be governed by Amdahl’s Law, and neither Ruby nor PHP can offer anything in that direction. jRuby is the future of Ruby, and jRuby is one of the dozens of new languages that people should consider using nowadays. But PHP has no variant that we can point to and say “That is the future of PHP”.

What I wish, above all else, is that I could get people to confront the question “Why would you choose PHP today?” The reasons to choose it in 2000 were compelling, but there is no reason to choose it today — the world has changed, and there are dozens of better choices now.