10 Reasons why PHP is Still Better than Ruby ;-)

1. Safety

Remember Gregg and Jason in their clips? The Rails guy goes to the beach while the PHP guy still tries to switch databases. Turns out hundreds of people die every year on beaches whereas the risk of dropping dead on your desk is next to nil. In fact, driving to work and most things you do during your spare time are far more life threatening than working on code and therefore the longer it takes, the better for your own personal safety.

2. Semicolon

Programming languages without a semicolon at the end of each line are like a fish without a bicycle. Nuff said.

3. DRY won’t Pay your Bills

Unless you’re workin on a project of your own, producing as little and maintainable code as possible will mainly up your paycheck. You spend less hours copying and pasting, less hours fixing the same bug on ten different lines and less time finding bugs in the first place. But remember: Time equals cash when you’re contracted by the hour. So we should be grateful for PHP and frameworks like Zend which make it so ridiculously easy to write the most cumbersome code full of duplications.

4. Namespaces

Colliding classes which happen to have the same name can indeed become a problem, however, Ruby-style namespaces with module MyNamespace are by no means the only solution. The makers of PHP chose not to overload it’s lean syntax with such unneccessary keywords and urge coders to prefix the class name like class MyNamespace_MyClass instead.

Nevertheless, in order to satisfy those who still long for namespaces, PHP will support as of the yet to be released version 5.3.

5. Goto

The presence of a goto language construct has been considered evil for decades now, yet not the keyword itself is evil but what a tiny minority of coders would use it for. In other words: Messy software developers are used as an excuse to discriminate the Methuselah of keywords.

Discrimination is fundamentally wrong! The makers of PHP have realized that and will as of the upcoming version 5.3 whereas for Rubyists the (categorized Library/Evil) is not even available as a gem.

6. Elseif

Cascading if clauses contain at least one “else if” case, so the natural way to name this keyword is elseif – as does PHP. Ruby on the other hand uses elsif which is so much harder to remember.

7. Solid and Static Foundation

Ruby is a highly dynamic programming language which allows you to twist and tweak almost every aspect of it. Therefore all it takes is for someone to accidentially monkey patch the + method of Float and your application goes kaboom. PHP on the other hand has a rock static foundation which means array_uintersect_uassoc() does exactly what it sais, which is… well, check the documentation for that. And if you absolutely must change it’s behaviour, you can always write your own my_array_uintersect_uassoc().

8. Elegance versus Expertise

Andy Jeffries compares the following snippets in his blog post .

PHP:

$foo = array("zulu" => "1", "alpha" => "4", "golf" => "8", "bravo" => "3");  
$keys = array_keys($foo);  
sort($keys);  
$bar = array_slice($keys, 0, 3); 

Ruby:

foo = {"zulu" => "1", "alpha" => "4", "golf" => "8", "bravo" => "3"}  
bar = foo.keys.sort.slice(0,3)

Admittedly, the Ruby syntax is more elegant and easier to read. However, if elegance is your aim in life, you’d better become a poet. Fact is that my granma could read and understand this piece of Ruby code whereas it takes a lot more expertise to figure what the PHP snippet is doing. Software developers should face the fact that they are paid for expertise, so making things hard to read – best coupled with poor documentation – will make you less disposable on the long run.

9. Less is More

The statistics of available extensions as of 2009-06-04:

Language	Appearance	Extensions	Ext per Year	Sources
	1987	15461 distros	703 distros
	1995	7326 gems	523 gems	and (forks not counted)
	1995	749 packages	54 packages	and

At first sight this seems to be bad news for PHP as it falls way behind the others with Ruby closing in on Perl. Then again in the real world with real customers it’s much easier to get a fair price for your software project if you can sell bits and pieces with: “There is no solution available out there, we’ll have to do it ourselves.”

10. Bugs are your Friends

You just have to learn how to sell them, too. Don’t believe the “half a product, not a half-ass product” stanza by the nice yet overly idealistic folks at 37signals (, ). The real buck starts flowing once you force your customers to constantly upgrade or even contract your consulting services.

This said, PHP is the ideal choice. There are testing frameworks out there, even has made it to the PHP world, but fortunately the PHP syntax is twisted enough to make the descriptions quite illegible. Compare the code samples from the two project webpages:

RSpec:

require 'bowling'

describe Bowling do
  before(:each) do
    @bowling = Bowling.new
  end

  it "should score 0 for gutter game" do
    20.times { @bowling.hit(0) }
    @bowling.score.should == 0
  end
end

:

require_once 'Bowling.php';

class DescribeNewBowlingGame extends PHPSpec_Context
{

    private $_bowling = null;

    public function before()
    {
        $this->_bowling = new Bowling;
    }

    public function itShouldScore0ForGutterGame()
    {
        // allow 20 throws
        for ($i=1; $i<=20; $i++) {
            $this->_bowling->hit(0);
        }
        $this->spec($this->_bowling->score)->should->equal(0);
    }

}

By working with PHP you can rest assured that 99.9% of the lines of code out there won’t come with tests and given the syntactical challanges that’s not going to change. Therefore, PHP is the perfect ecosystem for bugs to grow and continue to play an important role in selling bugfixing to customers.

()

Find this bit of information useful? Get more by subscribing to our .
Permanent link — Add on del.icio.us — Add on Technorati
Previous article: Easy Screencast Creation. Next article: Pimp Your .autotest.