(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.

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.

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.

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.

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.

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.”

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.