"That means that it can scale from anywhere from something like a 16 year-old's shared-host fanfiction site to say Whitehouse.gov."
Scaling to Whitehouse.gov is not impressive at all. Like a 16 year-old's shared-host fanfiction site whitehouse.gov really is nothing more than a content site, albeit a very large one.
The problem is Drupal isn't content to simply be a CMS. It has to pretend to be a framework for developing web apps as well, and for that it's just plain terrible.
If you compare it to a framework it loses, obviously. It's massive and complicated. And while PHP's is trying hard to modernize, the tools and ecosystem still don't compare to Ruby or Python (see below).
Drupal is only for when what it (or modules) can provide is a vast majority of the requirements of the project. Anything that couldn't be described as "nothing more than a content site" probably would not be a good fit.
The only thing it has to offer is when what you need is one of the myriad things it can be configured to be, because then you get a bunch of community eyes and tests on a bunch of code you didn't have to write.
Edit: Discussion on recent improvements to PHP's and its ecosystem (which are exciting progress in a direction I believe there is more room to go) http://news.ycombinator.com/item?id=4605715
> And while PHP's is trying hard (see the other story on the front page at the moment) to modernize, the tools and ecosystem still don't compare to Ruby or Python.
What do the current offering of PHP frameworks lack that Python/Rails provide?
I'm not going to claim up-to-date in-depth knowledge of the PHP ecosystem since my daily work ended in the 4/5 transition era, 6 years ago. So PHP is loads better, I'm sure, but I've seen the announcements of new features such as namespacing and closures, and it's clear that this stuff is shoehorned into the language and good use of these features is not ingrained into PHP culture.
In the case of rails, beyond the easily copyable superficialities of the MVC pattern, simple ORM and HTTP helper methods, what you have underneath is the elegance of the ruby OO model.
The ruby OO model with its mixins, implicit metaclass (eigenclass), and dynamic nature (ie. class definitions are just executable code), and standard functional features like lambdas w/ closures are all designed into the language in a very elegant way and this basic model has been more or less stable for the nearly 20 years of ruby's existence.
This means ruby code has a more consistent style and set of powerful idioms over time. Obviously there's a lot more shit ruby code getting written these days then there used to be, and modern PHP has a ton of power that can be leveraged very elegantly. However if you look at the corpi of popular open source ruby code vs popular open source PHP code over the years, you find a much higher bar of quality in the ruby code. Some of the attraction to the average rubyist is aesthetic, but that's not the whole story.
> and it's clear that this stuff is shoehorned into the language and good use of these features is not ingrained into PHP culture.
Every major PHP framework uses both namespacing and closures.
> The ruby OO model with its mixins, implicit metaclass (eigenclass), and dynamic nature (ie. class definitions are just executable code), and standard functional features like lambdas w/ closures are all designed into the language in a very elegant way and this basic model has been more or less stable for the nearly 20 years of ruby's existence.
What you're describing here is the difference in the language itself. The PHP OO model is more traditional and Java-like, but that doesn't implicitly make it worse or behind the times.
> However if you look at the corpi of popular open source ruby code vs popular open source PHP code over the years, you find a much higher bar of quality in the ruby code.
I can't speak for the Ruby side, but on the PHP side you couldn't be more wrong. The open source efforts in PHP in the last 5 years have been nothing short of excellent. The open source PHP community has completely adopted the full range of PHP features, unit testing (TDD and BDD), and coding standards (https://github.com/php-fig/fig-standards/tree/master/accepte...). This is nothing new and it's been like this for a while.
> Every major PHP framework uses both namespacing and closures.
No True Scotsman argument.
> The PHP OO model is more traditional and Java-like, but that doesn't implicitly make it worse or behind the times.
I don't care for fashion, so "behind the times" is neither here nor there, however a Java like OO model is definitely worse on most axes except foot-shooting and style-uniformity for large teams. If I want strong typing I want a system that leverages its power such as Haskell, not something like Java where compilation errors are mostly trivial things and I still end up with null pointers all over the place which is exactly the same as the most common type of error in more powerful dynamic languages. Beyond that, saying PHP OO is like Java is doing PHP a huge service because Java started out as OO with quite a strong vision. It may not have been perfect, and it's certainly developed its warts over time, but the seed of conceptual integrity in Java's OO is an order of magnitude more robust than PHP's.
> I can't speak for the Ruby side, but on the PHP side you couldn't be more wrong.
I was specifically making a comparison between PHP and Ruby. Making a one-side claim is a nonsensical response.
Kind of, but not really. The two major framework players in the PHP space right now are Zend Framework 2 and Symfony 2. This isn't really a "No True Scotsman" argument because both are headed up by reputable development shops (Sensio and Zend).
Both use namespaces.
> I don't care for fashion, so "behind the times" is neither here nor there, however a Java like OO model is definitely worse on most axes except foot-shooting and style-uniformity for large teams. If I want strong typing I want a system that leverages its power such as Haskell, not something like Java where compilation errors are mostly trivial things and I still end up with null pointers all over the place which is exactly the same as the most common type of error in more powerful dynamic languages. Beyond that, saying PHP OO is like Java is doing PHP a huge service because Java started out as OO with quite a strong vision. It may not have been perfect, and it's certainly developed its warts over time, but the seed of conceptual integrity in Java's OO is an order of magnitude more robust than PHP's.
Err, what? I'm not sure if I'm misunderstanding you here -- because PHP didn't have OO designs early on somehow that makes it's OO model less robust then Java's? I'm not going to bother arguing that point, but it certainly doesn't make me a less efficient developer. PHP's OO model is more than adequate for most web applications. I'm also not following the null pointer issue. Proper unit testing should vet null value issues out whether you're using a dynamic language or not. PHP has the (arguable) advantage of not completely shutting down when this mistake occurs.
> I was specifically making a comparison between PHP and Ruby. Making a one-side claim is a nonsensical response.
Not anymore of a one-sided claim than your own. You haven't done a lot of research into what's going on in the "popular open source PHP code" if you think your opinion is two-sided -- I'd strongly challenge you to point out what popular modern open source PHP code is inferior to popular modern open source ruby code.
It's not about frameworks so much as whether people use them. In Python and Ruby, pretty much everyone knows to look for useful gem or pip packages and uses frameworks and does a good job of avoiding reinventing wheels. In PHP, there's still a lot of old-guard cowboys and new blood that want to emulate them which aren't participating in the ecosystem, so the availability and quality of reusable code isn't there yet.
Scaling to Whitehouse.gov is not impressive at all. Like a 16 year-old's shared-host fanfiction site whitehouse.gov really is nothing more than a content site, albeit a very large one.
The problem is Drupal isn't content to simply be a CMS. It has to pretend to be a framework for developing web apps as well, and for that it's just plain terrible.