I disagree. The developers of Wordpress are not "the average person". There are too many production sites that run on PHP to say it's garbage.

No, it does mean it's good. You're comparing opinion (everybody has one) with actual hard real world results (tons of major sites with million hits running on Wordpress and around 15% of the web too).

I mean nobody in the almost literal sense. Stack Overflow serves as a rough barometer of popularity and either Symfony users have no questions, use another support platform, or they don't make up a significant population.

The #1 problem with the PHP community is it's complete anarchy and filled with people that should not be developing web apps, or at least should not be developing the way they're going about it.

Maybe Symfony could fix that, but there's a lot of work to be done here.

I am specifically talking about Symfony2, by the way.

A great number of frameworks and CMSs are using Symfony2 components. Two popular ones are the http-kernel and http-foundation components.

Drupal is integrating several Symfony2 components.

Composer, the PHP package manager that has taken the community by storm, is using Symfony components.

eZ publish is integrating several Symfony2 components.

Joomla! adopted YAML, using a Symfony2 component.

Stating that Symfony2 is not widely used simply tells me you're not keeping up with the PHP community - which would be fine if you're not a PHP developer, but makes your statement not trustworthy.

edit: PHPUnit, the defacto standard PHP unit testing framework, also uses Symfony2's YAML component.

I can go on.

Nobody uses Drupal, or eZ Publish or Joomla. They just don't. There's good reasons for this, notably these are some really obnoxious platforms to build for, but that aside their impact on the PHP world at large is inconsequential.

PHP, by and large, consists of people slamming together applications from the ground up the same way they built them in the 1990s. It shouldn't be this way, and people should fix it through education and outreach, but I really don't see that happening on the scale that's required.

Also, if you think even a quarter of the PHP devs out there even know what a unit testing framework is, you're more of an optimist than I am.

You could probably build a competing CMS in, say Laravel 4, replace the plugin system with Composer packages or something similar, use Twig and PDO out of the box, and have a much more elegant and modern system that probably almost no one would use, unless the user experience was just as brainless as it is with Wordpress.

Which is also one reason why, I think, despite all the arguments in their favor, static site generators (which do get mentioned now and then as an alternative to WP) still have a while to go before they're ready for mainstream use. It's not enough that it's well coded, it has to be easy too, and easy wins out over pretty every time.

WordPress is being pushed only because the majority of web developers can tinker with PHP only.

I think you're forgetting that most of the people who use Wordpress aren't web developers at all, and most of the 'web developers' who use Wordpress probably can't code much, either, because they won't need to. The ease of the Wordpress install is something they advertise. Once you ever have to touch the code, yes, it's a nightmare, even if you're inured to the horrors of php code. Most 'web development' jobs with Wordpress involve the install, setting up themes, maybe editing the css and installing plugins (because even that is still more arcane than some non-technical bloggers and people want to deal with.)

The "low bar for entry" for PHP comes up as an epithet now and again, but if you're trying to increase the adoption of your particular language, having an application the plebs can run isn't necessarily a bad thing. Does anything similar exist in the Python or Ruby worlds yet, for which someone wouldn't be expected to know how to use a terminal, or handle git?

It is, I think, almost entirely down to being less of a hassle than anything else out there, and especially less of a hassle than anything not written in PHP. Call it laziness if you will, and I wouldn't entirely disagree with you.

PHP is like Perl blended with C and a whole lot of confusion.

Frameworks have made it "better" like ketchup improves the quality of prison food, but it's still terrible on the whole.

A sane engineer don't pick technology based on what is most theoretically pure, but based on what can deliver on the requirements on time and on budget.

If you are building a simple CRUD style application, for example, there's likely nothing in your technical requirements that precludes PHP in any way. Then the question turns to ease of deployment and maintenance, operational costs, cost and availability of developer time, and there PHP tends to score quite well, not least because there's a huge pool of relatively skilled engineers that know it.

I personally prefer Ruby and don't like writing PHP at all, but I'd be a horrible engineer if I wrote it off in situations, where, e.g., it is hard to hire Ruby developers at a reasonable price, or there's a lot of existing PHP knowledge within a team that is already in place.

If you can find RoR developers, they are not cheap. If you're building a v1 product on a limited budget, and don't want to spend 80 hours per week writing it yourself, PHP is an excellent choice.

Having to read the code with a clothespin on your nose is a small price to pay.

Are there automated deployment tools written in PHP for PHP applications? I mean ones that can be taken seriously.

What optimization options do you have for PHP? What latitude do you have with hosting? If you're not Facebook, writing your own PHP engine, you're going to be stuck with one of a few that are generally crappy.

Cost and developer time are non-factors since the time you'd need to learn PHP is probably higher than other languages that make more sense and aren't filled with anachronisms you will spend half your time working around.

You can train someone up in Ruby on Rails in two weeks. Django or Node would take about double that time, but only because the platforms aren't by default as feature complete and the tooling will vary from project to project.

If you think that, you don't have much real world experience.

> Are there automated deployment tools written in PHP for PHP applications? I mean ones that can be taken seriously.

Why do you need a deployment tool written in PHP for PHP applications? Are you serious? It's a ridiculous proposition to care that much about the language the deployment system is written in. What I care about is what benefits it brings me.

Where I am now we have our own deployment system, btw. - we operate a private multi-tenant cloud specifically tuned to the type of workloads our customers have, at a cost ~1/3 of what it'd cost us to host our current infrastructure somewhere like EC2 with equivalent redundancy and performance. That is including the development and maintenance costs for our in-house tools. As part of that we have a rapidly improving set of deployment tools. Handling deployment of PHP was pretty much the simplest part of that system.

> What optimization options do you have for PHP? What latitude do you have with hosting?

Are you for real? I love Ruby. I'm working on a Ruby compiler as a hobby. But scaling PHP is trivial compared to RoR. I don't need optimization options for PHP - one of our clients processes restaurant bookings worth 50 million pounds a year via a setup that consumes ~30% of CPU resources on two frontend servers with a combined leasing cost of ~1000 GBP/year. The vast majority of their cost (their total yearly cost for their internet presence is about 3 orders of magnitude above the cost of the servers hosting the PHP code) for this system is marketing, support, power and bandwidth in that order. Cost of the frontends that PHP run on comes at the very bottom - it's a rounding error. If we needed more frontend capacity? We'd add another couple servers like that, and it's still be <1% of their cost.

What costs us money on the hardware side is database servers and network infrastructure. Web frontends for typical simple web apps are cheap. Sure, there are exceptions (but as much as I love Ruby, RoR is certainly not going to save you scalability grief in the cases where scaling PHP becomes hard or costly).

> If you're not Facebook, writing your own PHP engine, you're going to be stuck with one of a few that are generally crappy.

If you're not Facebook, there's no compelling reason to write your PHP engine as PHP is fast enough for pretty much anything you throw at it until you're in a situation where you have thousands of servers, where shaving a few percent off here and there starts creating large savings.

A vanishingly small number of companies ever reach that scale - optimising for that in advance is lunacy, and most "cleaner" languages does not provide a better starting point in that respect. Ruby, for example, is far more costly to scale.

> Cost and developer time are non-factors since the time you'd need to learn PHP is probably higher than other languages that make more sense and aren't filled with anachronisms you will spend half your time working around.

Spoken as someone who doesn't know the market. I have a steady supply of qualified PHP staff. In fact, we have recruiters hounding us every day with cheap candidates that know PHP. Ruby? Rarely, if ever. Those who know Ruby well enough have an easy time finding better paid jobs.

> You can train someone up in Ruby on Rails in two weeks

Bullshit. You can get a senior developers that is already expensive to relative beginner level in that amount of time. Or you can hire a PHP developer that is already skilled at ~60% of the cost.

I've seen "RoR developers" with two weeks experience, and what they produce is not pretty, and certainly does not result in a good ROI compared to more pragmatic solutions. I'm all for using Ruby if/when you have a good team of Ruby developers, but you then also need to realize that you have an expensive team. It makes sense when your team is highly experienced and rapid turnaround is more important than keeping the cost down, or if your personal satisfaction is more important to you than the cost - both can be perfectly valid reasons. If I were to start a new company now, I'd pick Ruby myself. But I would do it because it is what I would prefer to work with, not out of any illusion it's currently a cheap choice.

"Cost and developer time are non-factors"

Bro, do you even startup?

His point was that learning PHP properly with all the shenanigans takes at least as much as time as learning a well thought out environment.

It's not snobbery. It's called doing your job like a professional. This is harder in PHP than it is in other languages.

The only language more cantankerous and difficult than PHP is C. Learning PHP properly is hard. There are hundreds of little things you will have to be very careful about because they are easy to get wrong and the cost of failure can be enormous.

If you can't see this, you're basically a PHP snob. You're holding your pet language to a different standard than others.

I detest PHP from a language writers standpoint. Programming language design is a hobby of mine, and I am a real snob about programming languages from a personal preference point of view, and PHP certainly does not measure up.

But I don't let my pet ideas about what a programming language should be like stop me from doing my job, which is to ensure we have an environment and team where we can get projects in on time and on budget with a staff that is both skilled enough and cost effective enough to keep us profitable. Is it possible to do this with Ruby? Sure. But the dynamics are very different, and the potential customers tend to be quite different.

I've written web services in a number of languages, including C and C++, and been responsible for systems in a mix of PHP and Perl that handled ~$50 million worth of card payments and invoicing, and I've developed Ruby based systems and hybrid PHP - Ruby - C++ stacks. When I can justify picking Ruby, I do, because I love the language. But I refuse to pick Ruby just because I personally like it and it has a higher coolness factor in the face of economics where it doesn't make sense, such as when there's installed bases or teams that are already skilled at PHP. It'd be irresponsible.

You don't have to use those things, but they are there if you want them, just like they are in other languages. Neither Python nor Ruby enforce unit test or parameterized SQL requirements.

I don't like the language itself, but I do like the myriad benefits it brings. The only pet language I hold to a different standard is Perl.

I agree that if you already know another platform there's no reason to switch to PHP, but similarly i've not seen much reason to switch away from PHP, aside from personal preference in language syntax.

Contentious. The VM itself is, but there are many functions implemented in C. Whether it'll be fast or slow for your application is not necessarily immediately obvious.

Wikipedia's Mediawiki software is awful, and serves as a great example of how not to build an application. It makes WordPress look like a precision engineered Swiss watch.

Yahoo uses PHP because, like Facebook, they could make FORTRAN work in production if they wanted to.

Facebook's former CTO has said that the only reason Facebook is still on PHP still today is legacy. It wouldn't be written in PHP if it were started today.

PHP once was the right tool for the job, but those years have passed. We have many better options now.

A sane engineer considers the full pictures before picking a solution rather than pick their pet languages just because it's nice and clean.

Inertia is powerful.

Though, to be honest, I don't think that using Play (today) or Rails/Django (yesterday) is sufficiently less productive to merit the technical debt you almost certainly will incur starting with a PHP stack. (And I am an ex-PHP person, to the point of hacking around in PHP core...that's a few months I'd love to have back.)