Planet CakePHP

So it seems that I didn't provide the best of examples in my last post, when explaining why I chose Ruby on Rails instead of CakePHP for developing Codaset. So I decided that I will write 10 [solid] reasons, why Ruby is better than PHP. After all, that is why I chose it.

I already explained a little bit about the aesthetics of Ruby, and how you can write a method without the need for any curly braces or even parenthesis. So I think I will leave the aesthetics alone for a little bit.

What a wonderful Objectified world!

I think one of the most significant differences between Ruby and PHP, and perhaps the basis for a lot of other features of Ruby, is that everything in Ruby is an object. Even though PHP supports Object Oriented Programming, OOP was not even thought of when PHP started out. OOP was simply hacked into the language, and so is not a pure object-oriented language. That is because it uses primitive types; things that are not objects. We use primitive types all the time in PHP. Things like integers, floats and strings are all primitive types. Pretty much all we can do with them, is store data in them and pass them around. On their own, they do very little.

Ruby is a pure object-oriented language, and it was built like that from the start.

So why should I care? I hear you say. Well, because everything in Ruby is an object, everything accepts method calls, even nil. (nil is Ruby's equivalent to PHP's null.)� In PHP, a string isn't smart enough to do anything on its own. If we want to get the length of a string, we would have to call a separate function, and pass the string to it:

PHP
$my_string = 'Just another string';
echo strlen($my_string);

With Ruby, we can ask the string directly, to tell us its length:

RUBY
my_string = "Just another string"
puts my_string.length

FYI: PHP variables always start with a dollar sign $, but Ruby doesn't have this requirement. Yet another keystroke saved. Yay! You also may have noticed that we also don't need to type the semi-colon ; at the end of each line in Ruby. You can, but you don't have to, unless of course the above two lines are placed on the same line. In which case, the semi-colon will be needed to separate the two.

We could also write the above ruby code like this:

RUBY
puts "Just another string".length

Chicken or Egg?

One of the biggest frustrations for me when it comes to coding in PHP, is the need to memorise the order of arguments to the language's many global functions. I've been coding in PHP for over 10 years now, and I still have trouble remembering which argument comes first in a function call. Was it the chicken or was it the egg?

For example, let's take the in_array function:

PHP
in_array($chicken, $egg);

And then lets compare that with the array_push function, which takes its arguments in the reverse order:

PHP
array_push($egg, $chicken);

Most of PHP's array functions take an array as the first argument, but there are a few exceptions. Inconsistencies such as this can get very frustrating, and PHP is riddled with them. When you don't know any differently, you tend to overlook these. But ever since I started working with Ruby, these little annoyances actually become big annoyances.

But this is the nature of PHP and it's procedural programming design. Fortunately, Ruby solves this problem with object orientation. Lets look at Ruby's equivalents to in_array and array_push.

First we create an array and assign it to the fruit variable:

RUBY
fruit = ['apple', 'orange']

Then we check to see if 'banana' is in the fruit array. This is the same as PHP's in_array function:

RUBY
fruit.include? 'banana'

So the above obviously returns false, as 'banana' does not exist, or is not included in the fruit array. So lets push it in:

RUBY
fruit.push 'banana'

And now fruit equals ['apple', 'orange', 'banana']

In Ruby, an array is an object, so if we want to push a variable into the array, we simply take that array and just call push. It needs only one argument, since the method is attached to the object on which it will operate. And we now have no source of confusion.

Not only does this help with remembering arguments, it also helps to organize the Ruby code space. Instead of having many procedural functions in a global space like PHP, Ruby packages all its methods nice and neatly into the objects that actually need them.

Of course, there are many more reasons why objectifying everything can help you, but these are some of the most notable. But I hope you can see that Ruby's object-oriented nature actually makes life simpler.

In my next post where I explain reason #2 as to why Ruby is better than PHP, I will attempt to explain and show you one of the biggest differences, and the reason why developing plugins in Rails is so powerful.

Thanks for tuning in guys, and don't forget to leave your comments. I'd love to know your thoughts and opinions.