What a Dump!

I see it time and again: people dismiss Perl as ugly looking and hard to maintain. As we all know this is because Perl lets you do all sorts of elegant things; whether or not you should is another matter, and Perl Best Practices stands as a very nice guidebook of do's and don'ts. I know my code certainly improved after reading through it.

Ruby seems to escape this criticism, and yet it can be every bit as ugly. A lack of curly braces around definitions takes some getting used to, and it makes a poorly indented application hard to read at a glance.

Another big departure was in the lack of line separators (;), or perhaps I should instead say that they're optional. While I can see the argument that this forces readability via-a-vie a one line, one statement structure, the fact that line separators can be used removes this benefit.

Lesson: You can make Ruby every bit as messy as Perl if you want to.

OOPs and Infrastructure

Here I see a very clear benefit to Ruby. No doubt this speaks more to my abilities with the language, but I learned Object Oriented programming with Java, and moving into that particular area in Perl was cumbersome.

Ruby, on the other hand, is OO from the ground up, making it more friendly to the Java trained OO programmer. Or at least to this one. Ruby takes it a step further though, and does away with primitive types, and the result is some very clever infrastructure. An array variable, for example, is an instance of the Array object, and contains useful methods for working with the array; iterators, for example. Hashes work similarly.

From this Perl programmer's perspective, it takes some getting used to. Instinctively one wants to write

foreach my $member @array { ... }
[download]

rather than

array.each { ... }
[download]

Then again, that's a habit that one learns to change. Which brings me to the next item.

The Variable Appearance of Variables

Perl programmers have got used to being able to tell what they're looking at at a glance. $scalar, @array, %hash are all great ways of being able to figure out what sort of data you're working with at the moment. No looking back to see if c was declared as an int, a char, or a float. Easier to keep track of what you and other people are doing.

Ruby doesn't use this convention, and boy did I miss it. The @ character makes an appearance to signify a class an instance variable, and two of them together (@@) make a class variable, but that's it. The fact that hashes and arrays are both indexed using square brackets ([]) contributes to the confusion. It's good that these elements are present, but it's a potential pitfall, and again, it takes some getting used to.

Also, it helps you appreciate one of the ways that Perl is more readable than its counterpart.

Testing and Documentation.

Perl and Ruby both provide excellent testing and documentation facilities. Where Perl has POD, Ruby has RDoc. Where Perl has Test::More, Ruby has test/unit. Both are invaluable tools if used properly, and it's worth taking the time to get to know how to used them.

Community Support

There is no CRAN, and there are no Ruby Monks. That's not to say that Ruby doesn't have it's own module system (rubygems.org), but it's nowhere near as robust as CPAN. Likewise, I managed to find some folks to answer questions I had in irc, but Perl monks it is not.

This is, I think, a reflection of the relative maturity of Perl to Ruby. With a decades long an eight year head-start, Perl has grown a community of developers; many of whom have been willing and eager to post the best of their libraries for others to use. It's those same developers that can lend their time and expertise to those of us who might not know any better. Ruby has neither of these things because it hasn't been around long enough. Given another decade, that may change.

Conclusions

Ruby is an excellent language, and I'm interested/eager to learn more about it. With a variety of Ruby related modules on CPAN, interoperability between the two languages doesn't appear to be out of the question. It seems to me that Ruby will make a better choice for OOP when it's called for, and can be an excellent way of rapid prototyping class hierarchies before developing them in another OO language.

That said, I've always believed that the strength of any organization is in its people. Perl provides the model of a development community that other languages strive for, and as a result, when I'm presented with a task that seems unusual, awkward, or that requires fitting the square peg in the triangular hole, Perl will continue to be the natural choice.

Further Reading

1. http://use.perl.org/~jmcada/journal/32457
2. Thomas, Dave. Programming Ruby, The Pragmatic Programmers' Guide. Pragmatic Programmers, LLC. Raleigh, 2005.
3. Introduction to Ruby for Perl Programmers

Update: Thanks to the monks who have corrected some of my errors. I have made changes in the above text that incorporate their edits, while leaving the original incorrect data present and struck through.