In which I do a little digging about the choices I've made with PHP. This is a long read, but it isn't something that can be explained in one or two paragraphs.

blog - Explaining My Choices Further.md

In the comments from my last post and on Twitter I noticed a lot of people who had something to say about PHP. The comments were varied but they usally sounded something like this (sorry @ipetepete, I picked yours because it was the shortest).

...the little bits of soul from all of us who've had to work on, and or maintain large PHP applications. – ipetepete

In Pete's defense, he did go on to say that rest of the stack I was using was a "smorgasbord of awesome". Thanks, Pete. I agree!

I would, however, like to take a little time to correct a misperception in the developer community about PHP. I recently got into this same... discussion... with Jeff Atwood, and I seem to be running into it more and more. So here goes. Please bear with me as I cover a little history further on.

Pete, and everybody else, you're exactly right. There are a frightening number of PHP applications out there that are just awful. Awful, awful, awful. At my previous job I inherited a custom PHP ecommerce site that was absolutely foaming at the mouth with technical debt. We're talking the Nile River of procedural code here. Even after a solid year of working on it and modernizing the code base, I still wouldn't call it a "good" application. Its good enough to not get hacked into oblivion now, basically. And that was with a year of dedicated effort!

I think all of us that have worked with or even touched PHP can tell some variation of this story. Multiply those horror stories out across tens of thousands of developers and then toss in this lovely mix of terror: Wordpress, PHPBB, osCommerce, Magento, the list goes on... and on... and on... and ON.

Is it any wonder that developers have this knee jerk reaction to PHP as some sort of torture device that sucks two or three years of their career down the drain as they futilely attempt to keep some ancient, crumbling relic of a code base on life support? The 2000's are littered with the remains of open-source projects and applications that are a testament to the wild, untamed nature of PHP. At a previous job I had a client call and request that we redo part of her Magento web site and I literally got a sick feeling in the pit of my stomach.

When you look at it from that perspective, reactions like Pete's are perfectly normal! Nothing to argue about here; move along, move along.

A little history & a revolution

PHP didn't even start to see "frameworks" emerge until 2005 (the earliest references I can find of the Zend Framework are back in 2005, although the first stable production release wasn't until 2007). Symfony 1 didn't get started until 2005. Even then there was zero interoperability. My knowledge of Joomla's framework didn't carry over into other frameworks because there wasn't any shared code. The whole while, swarms of people were endlessly reinventing the same rusty, broken wheel over and over again.

The Visigoths never invaded, in the Ruby world. While the PHP world was desperately trying to convince people to even use what fledgling frameworks there were, the Ruby community was inventing Gems (2003), Rails (also 2003), Rack (2007), and other great tools.

PHP didn't see its first real package manager, Composer, until late 2011. Since then, there's been an explosion of packages available for PHP. It isn't a fad - the statistics speak for themselves. 10,000 packages available. Nearly 20 million packages installed since this time last year. Things are changing rapidly. The Composer package manager might be the most revolutionary tool ever released for PHP.

You might be wondering where I'm going with this. Fair enough.

A little code

It is not 2007 for PHP anymore. There has been a significant change in the community - a revolution toward shared code and interoperability. We took the achivements that had been so thoroughly demonstrated by the Node and Ruby communities and latched on as tightly as we could. PHP Frameworks are sharing libraries. Standard tools are proliferating. Unit and behavior testing is being evangelized.

The days when programmers opened up a blank file, named it index.php, and said, "time to start coding!" are over. Projects are modular, and web applications are following the RESTful principles that Rails brought. I look at code from a Symfony 2 project and a Rails project and I see the exact same principles at play.

Here's an example controller action from the excellent Discourse project, written in Ruby for the Rails framework.

class TopicsController < ApplicationController
    
    #....

    def star
        @topic = Topic.where(id: params[:topic_id].to_i).first
        guardian.ensure_can_see!(@topic)
    
        @topic.toggle_star(current_user, params[:starred] == 'true')
        render nothing: true
    end

Here is my (rough) interpretation of how I would write this same action in PHP for the Symfony framework.

<?php

class TopicsController extends Controller
{
    //....

    public function star($topic_id, $starred)
    {
        $topic = $this->get('model.Topic')->find($topic_id);
        
        $this->get('guardian')->ensureVisible($topic);
        
        $topic->toggleStar($this->getUser(), $starred);
        
        return; //I would usually return a status code here, depending on success/failure
    }
}

Not that different, really. In both cases I see clean, maintainable code. There are some differences in how Symfony manages classes through its service container that make it a little more involved, but only just, and those are really a matter of preference. I could install a library that makes the code look almost 1:1.

Some stats

I have two applications that are in what I would consider "maintenance" mode (only bug fixes and minor improvements, no new features). One is Rails, the other is Symfony. Both are coded exceptionally well. I did not originally code either of them. I ran some Fogbugz reports and came up with the following.

• I spend more time managing and fixing my PHP code than I do Ruby code. About 2x as much.
• I spend more time managing how Ruby runs (configuration, deployment, versions, gems, etc.). About 2x as much as I do PHP.

I was a little surprised at how close the numbers were. It feels like I spend more time working on the PHP app but it really comes out as a wash when I factor in all the time I have to spend twiddling with the server for the Ruby app. (In Ruby's defense - this process gets easier and easier all the time.)

It turns out that the language doesn't matter - the technical debt is the same, either way. Almost zero.

Developers everywhere - PHP is not the same as it was even two years ago. Stop acting like it. The language and the community have both changed significantly. In many ways PHP is just now starting to come into its own. In many ways, the PHP community has gone back in time - back to relive the days that should have been spent building the tools and libraries that were never built. Another Magento is not going to appear. It will not happen. Stop worrying about it.

If we do see another wildly popular open source project emerge from the PHP world (and I firmly believe that we will) it will look far more akin to a project like Discourse. Clean, well structured, maintanable code.

Jeff Atwood has stated publicly that one of his ulterior motives with the Discourse project is get people to stop using PHP and start using Ruby. I like Jeff Atwood and respect his opinions but I truly believe he's speaking in ignorance here. He and many others look at the source code for projects like Wordpress (which has been around since 2003), recoil in horror, and feel like they're doing the wider community a service by making declaring a religious war against PHP.

If PHP hadn't evolved, Jeff, I would be right there next to you, carrying that banner.

But it has.

@mikl

readfile()? Well you would use

new SplFileObject($file)->fpassthru();

Do you expect them to remove readfile()? Then you would complain PHP always breaks backwards compatibility.

In my general day-to-day work my goal isn't to produce code; it's to solve problems. A majority of languages seem to produce lots of frameworks, utility libraries and single-purpose applications. I have much love for projects like Redmine, Solr, Hibernate, Twistd, etc. but they are either too narrow in scope for me to solve different problems with or they're frameworks and libraries that make things easier but still require me to spend a lot of time writing admin forms and menus. I chalk it up to the low barrier to entry, but PHP has produced arguably three of the most popular and widely supported open-source content management platforms. Not saying that any of them are good in terms of code quality, but they allow me to solve certain classes of problems better than anything else while not driving me entirely insane. If I had unlimited time and budget to get it right and it didn't need to altered by anyone else after I was done would I use WordPress or Joomla or Drupal? No. Would I use PHP? Probably not. But I don't have that job and my free time is similarly constrained.

I've only been developing with PHP for about a year, so forgive me if I'm being naive but surely, regardless of the language, we're building software to solve problems, a lot of the time for people who simply don't care how it's done, they just want it to work. So in that respect, the likes of Magento and WordPress are perfect solutions to their respective problems, regardless of whether they follow best practices to the letter...

I'm a big fan of PHP, perhaps because of it's forgiving nature. Whatever it is, it allows me to get the job done.