From the comments: "PHP is great for its purpose. Quick scripts that generate web content. It’s even OK for small applications. But just like C, PHP is lousy for the medium to large. Any software project with a duration in months or greater that is entirely in PHP is going to be painful."
Like Facebook? Or Wordpress? Or Digg?
PHP aint perfect, but it's demonstrably suitable for medium to large projects.
Do yourself a favor. Never ever use wordpress as an example of a quality PHP application. Please look at the source code, the open source wordpress is a monstrous hack that has no clear architecture, has a terrible system of hooks that plugin authors regularly abuse and doesn't scale unless you write your own hack of plugin to override the db handler so you can do things like r/w splitting or sharding.
There is little indication that Facebook isn't painful to deal with compared to a functionally identical version of Facebook built in another language/platform. Because someone did it and is profiting from it does not mean they could not have done it better.
It is called lex-pass [1], it does syntax aware transformations of PHP. Like sed, but specifically for PHP. There is a video that mentions it briefly at 2:00 min [2].
I thought most of Facebook's php is written in a subset of PHP that can HipHop can compile for them. I doubt their PHP is all that similar to eg. Wordpress's PHP.
Turns out * has some limiting factors [when serving 1 trillion page views a month]. Replace "*" with any piece of technology on the web stack.
There's not a single other company in the world (sans probably Google) that has to deal with performance problems on that level of scale. At that point, I can't imagine anything surviving out-of-the-box. Something has to give, even the language they're using (they're using a subset of PHP that they can run through a custom compiler to C++ machine code, to squeeze every possible CPU cycle out of the servers they have).
I think it's probably easier to create unmanageable spaghetti with PHP. It's not that you can't build a large project in PHP, it's that it's easier to foul up.
By far the part of PHP that shines for small projects and causes havoc in large is the way includes work. It's possible to be disciplined about this, but it's not common. I remember many times searching in vain for some function or another that was included somewhere, somehow. Sometimes even in code that I wrote entirely!
Facebook and Wordpress and Digg being in PHP isn't a decision that was made with a large architecture in mind, it was done because the people who wrote those projects knew PHP (And in Wordpress's case, because the people who use it need it in PHP).
One of our struggles at Facebook was actually with circular includes that made our php codebase super tasty spaghetti.
File A includes File B includes File C includes File A by about 10000 files.
It was for a very scary trying to change a core library during this time because it was almost impossible to figure out where all it was included and impossible to test all the code that touched it. Additionally, we were basically loading up our entire init stack on every page load and async request because as soon as you loaded up one file all the circular dependencies would load up the entire stack. This had a big performance overhead prior to our switch to HipHop.
To this end we developed a new include system for library files that forces developers to be sane. Every module in the our library files must explicitly include everything that they need and it forbids circular dependencies. If module A requires module B, module B cannot require module A.
Making this change took a long time (in some places we are still untangling the code), but our core code is now infinitely more manageable and most importantly testable.
We have a static analyzer that runs when we submit a diff yes or try to commit, but in our "require_module" we also check for circular dependencies at run time. If you create one you get the module stack dumped into your log and promptly exited with an error message.
You can't blame PHP because the developers using it write messy code.
I'll have the same problem in Java. I'll need to find out where I implemented some logic, and have to start digging through classes and following my own breadcrumbs until I find it sometimes.
Just because I commented my code poorly, or put logic in the wrong place isn't the fault of Java, it's my own, and the languages, Java and PHP, in my opinion, are easy and fun to work with for the most part.
It happens with any language. But at least in Java you're limited (as far as I know) to looking through what you've explicitly imported. If you include a file in PHP, you have access to everything that that file included in itself, and everything that those files included, and so forth.
Excuse my ignorance, but don't you have the same behavior with `require` in Ruby? How are the behaviors of Ruby's `require` and PHP's `include_once` different?
Today not many people create large apps without a solid framework at the bottom, be it Zend, symfony, Rails, Django or whatever.
Wordpress is pretty awful but the codebase is also pretty old, rewriting everything would be loads of work and make many plugins unusable.
It's a damning indictment of Java, ASP.NET, Ruby and all other environments that almost all of the apps that "any idiot can install on a web server" are written in PHP.
Where's the "Wordpress" of any other programming language?
There is a strong correlation between things whose primary design criterion include "any idiot can install", and "complete crap design".
As examples I hold up PHP, most PHP applications, MySQL, Matt Wright's script archives (a series of security holes masquerading as useful Perl scripts that were popular a decade ago), and so on.
The correlation is hardly absolute. For instance SQLite is both excellently well designed and also designed for easy install. However it holds often enough to strain coincidence.
My suspicion is that part of it is that something that is designed to be trivial to use tends to have a low barrier to entry to get involved with. This leads to getting contributers with more enthusiasm than skill.
Early on, PHP had the advantage of mod_php, which made deploying PHP applications simple and performed well. Because other languages required more complex setup (e.g. fastcgi, servlet containers) shared hosting providers gravitated towards supporting PHP applications. This caused open source projects that used PHP to gain more traction than projects written in, say, Perl. Eventually, hosting providers realized mod_php was not such a good idea. See the following link for an expansion on that http://www.majordojo.com/2007/11/is-mod-php-falling-out-of-f.... I think the shift of shared hosting providers to FastCGI (which makes supporting additional languages less work) as well as the decreased cost of private servers due to virtualization is playing a role in PHP's apparent decline in popularity.
Before there were lots of easy-to-use self-publishing apps, it made sense to install your own on a $5/month host. Most people nowadays use Wordpress, the service, not Wordpress the PHP package.
That's like saying because the Pyramids were built in stone, we should build all our skyscrapers in stone. I bet that if Facebook, Wordpress or Digg were built in Ruby on Rails or some other modern language, they would be exponentially faster and easier to develop and maintain.
Most of the time, performance is more a factor of system architecture and choice of algorithms/data structures - and less about the language you're using.
Unless you're doing very CPU intensive computations where every millisecond counts, the difference between most languages won't be that great in the big picture.
Like Facebook? Or Wordpress? Or Digg?
PHP aint perfect, but it's demonstrably suitable for medium to large projects.