4 Reasons Why Ruby Syntax Is Better Than PHP's

Having been a Rails developer for a little over a year now and after
completing a few Rails projects successfully, I thought I'd post a set
of reasons why I think Ruby has a cleaner syntax than PHP.

The worst
part of this for me is that PHP can fix a lot of these things and have
a much nicer syntax but in the interests of backwards-compatibility are
fairly tied to the current syntax.

1. Objects vs Functions

As Ruby is a pure OOP language as opposed to PHP's bolted-on functionality, doing things like multiple chained actions are a lot more readable in Ruby. Take for example a case when you have a hash where you want the first 3 alphabetically sorted key values. In PHP you'd do the following:

$foo = array("zulu" => "1", "alpha" => "4", "golf" => "8", "bravo" => "3");

$keys = array_keys($foo);

sort($keys);

$bar = array_slice($keys, 0, 3);

This seems incredibly verbose mainly due to - as Rob points out in the comments - the fact that PHP doesn't return the sorted array from sort. If it did you could do something like this:

$foo = array("zulu" => "1", "alpha" => "4", "golf" => "8", "bravo" => "3");

$bar = array_slice(sort(array_keys($foo)), 0, 3);

But even that seems arse backwords to me, it feels like you're defining what you're doing to the hash before you get anywhere close to the hash and then have parameters after array_keys and sort that aren't immediately (without counting back brackets) related to the slicing action.

Compare this to the ruby equivalent:

foo = {"zulu" => "1", "alpha" => "4", "golf" => "8", "bravo" => "3"}

bar = foo.keys.sort.slice(0,3)

This reads a lot more logically as the information builds from left to right like an English sentence. You could also make it more obvious you're calling methods by using the less Ruby-looking:

bar = foo.keys().sort().slice(0,3)

Or you could make it more ruby-like and use a range in array access style instead of the slice method:

bar = foo.keys.sort[0..2]

2. Hash As The Last Parameter

If you have a method that can take varying named options, Ruby has a very nice syntax where you can use symbols as the keys and it will automatically combined them in to a hash (associative array in PHP terms). Take the example below:

my_object.my_function(1, 2, :sort => "name", :limit => 10)

This can be done in PHP but it takes an extra array keyword and just doesn't look as nice because of the extra parenthesis:

$my_object->my_function(1, 2, array("sort" => "name", "limit" => 10))

Of course named parameters would be even better, but then again I'm not a Python developer...

3. Blocks

Ruby uses blocks (closures, lambdas and other related terms) throughout the language and are very useful for providing specific functionality in a single place that you wouldn't want to define a function for. For example, take the point of providing a custom sort option for an array of objects where you want to sort them by the object's price property. In PHP you'd do it like this:

function sort_my_objects_by_price($a, $b)

{

  if ($a->price == $b->price) {

    return 0;

  }

  return ($a->price > $b->price) ? +1 : -1;

}



usort($my_array, "sort_my_objects_by_price");

In Rails you'd do it like this (using the much shorter comparison operator doesn't help make this fair, but still):

my_array.sort do |a, b|

  a.price <=> b.price

end

That's much more readable. You can do something similar in PHP with create_function looking like this:

usort($my_array, create_function('$a, $b', 'if ($a->price == $b->price) {

  return 0; } return ($a->price > $b->price) ? +1 : -1;'));

(Thanks to Rob for the correction - reminder to self - don't post unless fully awake)

However, that's nowhere close to being readable and looks very unusual to any professional PHP developer. It's effectively "eval" which as everyone knows should really be spelt *evil*. Editors won't syntax highlight the code (even though Google's Javascript Syntax Highlighter does above) so it's not obvious if there are any simple errors.

Another time to use blocks is for content of helpers in a Rails-like situation or doing something to each element of a returned function.

Accounts.active do |account|

	account.notify_downtime

end

Of course in Rails for the above there's an even simpler way of doing it by using symbol#to_proc:

Accounts.active(&:notify_downtime)

4. Monkeypatching

This is something that creates a lot of debate in the Rails/Ruby communities anyway. For the PHP developers reading this, Monkeypatching is the act of changing base or built in classes such as array or string to add new functionality or change they way they work. It obviously then has the potential to create havoc in understanding why something is happening.

There are slightly better ways of doing it than just opening a class and adding your own function. For example, say you want to add a vat() method to all Fixnums to calculate VAT at the (current) rate of 15%. You could do it like this:

class Fixnum

  def vat

    self * 0.15

  end

end

Or you could create your own module and include it in Fixnum using something like the following:

module MyCompanyName

  module FinanceFunctions

    def vat

      self * 0.15

    end

  end

end



Fixnum.send(:include, MyCompanyName::FinanceFunctions)

This does the same thing but it means that the functions are separated for testing purposes, can be included in multiple classes without code duplication and it makes it a lot more obvious that you're doing it.

This example is fairly trivial but the point remains - considering and being aware of the risks, Monkeypatching gives you flexibility.

Your Thoughts

So, those are the top 4 reasons I prefer Ruby syntax to PHP syntax. What do you think? Am I missing some more obvious reason why Ruby is better than PHP (from a syntax point of view)? Can anyone provide an example of somewhere they think PHP syntax is actually better? Let me know in the comments.

Other articles you may like:

• 25 Tips for Intermediate Git Users
• Debug-level Logging for a Single Rails Production Request
• DTrace and Ruby on Rails with Leopard/Snow Leopard
• Real World Uses of Rails Metal and Middleware
• Review of the jQuery UI 1.6 Book

The content and design of this site is ©copyright and all rights reserved Andy Jeffries (2001-2010), unless specified.
This site is written in Ruby on Rails, hosted on an Apache/Passenger server on Bytemark hardware.
Please give an attribution if you reference/use the content on your site.