http://flow3.typo3.org/download/ This is still in alpha but has good source code regardless.

[1] https://github.com/facebook/lex-pass [2] http://www.vimeo.com/6699769

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

http://www.computerhistory.org/collections/accession/1026307...

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

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.

Do you have a static analyzer or something like it that enforces the no-circular-dependencies rule, or is it just a procedural thing?

http://phabricator.org/ has a very similar system if you are curious. epriestley made some nice updates to it in there as well.

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.

Where's the "Wordpress" of any other programming language?

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.

There's not necessarily any connection between developing external Facebook applications and working on Facebook code itself.

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.

I'll take that bet.