Eli Bendersky's website - Ruby

A subjective comparison between Perl and Ruby

2008-02-01T17:36:24-08:00

The goal of this article is to examine whether it's worth for me to switch to Ruby as my main programming language, a position currently taken by Perl. As the title states, it is subjective – in that it presents my personal opinions and targets my specific needs.

Introduction

First, some background. For many years now, Perl is my main go-to guy for programming tasks. As a hardware engineer, my "programming tasks" are not enterprise-level apps distributed for the use of thousands of customers, but rather support programs and scripts whose main customers are myself and my colleagues. Sometimes these programs have GUIs, sometimes they're even web-based, a lot of times they interact with other (mainly C++ for performance) programs, but most of them are scripts. Whenever some script has to be written for text manipulation, or a simple program for controlling some piece of embedded hardware, I turn to Perl. In size, these programs range from one-liners to several thousand lines of code (KLOCs).

Also, I must add that my platform at the time being is 100% MS Windows. In my previous job, I worked on UNIXes (Linux, AIX, Solaris), where Perl blends much better in the environment. But now I have to work with what I've got, and Windows is the platform. This means that I use ActiveState as the Perl distribution and have a keen interest in GUIs.

I'm always on the lookout for new tools and technologies to learn. Around two years ago, I decided to give Ruby a try, since I began hearing more and more about how cool it is. As I'm constantly lurking in the Perl community, so what gave me the push was seeing how several Perl hackers whom I respect recommend Ruby as a good future direction.

Anyway, in my last attempt, after a brief flirtation Ruby I decided to go back to Perl, as I found Ruby still not mature enough to be my go-to guy, mainly because of the lack of documentation, suitable libraries and the much smaller community.

Today, I decided to examine Ruby again, by first publishing a thorough comparison between it and Perl, in order to help myself make a learned choice.

First things first – the language core

In my opinion, Ruby's core is superior to Perl. Not much to think of here. And I'm definitely not one to be called a "Perl basher". I like Perl, I like its syntax, I like programming in Perl. But Ruby is better.

Ruby is everything Perl is, and more. You can write any Perl code in Ruby, in a very similar way, but Ruby offers several definite improvements. Here are a few I deem most important:

Object-orientation from the ground-up. Personally, I feel that while OOP is not the silver bullet, it helps in keeping large bodies of code maintainable. Writing OO code in Perl is painful, in Ruby a pleasure.

Convenient, built-in exception handling.

The support for functional features is better than in Perl. Blocks, procs, lambdas, and all that. I feel very grateful to Ruby for providing convenient means of replacing several of the things I previously thought require the power of Lisp macros.

Metaprogramming, better support for code generation and embedded DSLs.

So there's no question here, at least for me. Had everything else been equal, I would certainly pick Ruby. Alas, things are never so simple.

Performance

According to the shootout, Ruby is 4-5x slower than Perl on average. This is not a major difference – I wouldn't use Perl for heavy number crunching anyway. Besides, Ruby has an alternative virtual machine named YARV that should enter service any time now™, and is expected to improve the performance by at least a few 10s of %s.

When you need high performance, you'll have to resort to C/C++, and both Perl and Ruby have good bindings for these languages.

Documentation and libraries

I place these two together, because I think they're very much related. The sample people who spare the time to write useful modules, also write good documentation for their and others' modules.

In this section, Perl wins big. Perl's library of code, the mighty CPAN, is incomparable. Maybe Ruby is not far from Perl in popularity today, but this is a recent event. For many years, Perl was more popular by orders of magnitude, and accumulated a huge library of shared knowledge.

Documentation in the Perl world is also better. Funny, because I find the RDoc to be much better than POD. Documenting Ruby code in a standard way is far simpler and more pleasant than with Perl – where embedding POD feels like programming in the 80s. But yet again, Perl's huge lead over a long time ensured that most of the libraries are quite well documented and there are tons of examples and snippets to be found online. Ruby is catching up, but this will take time.

Just one example: XML handling. Ruby's canonical solution is REXML – a slow, unconvenient API with appalling error handling. I was so disgusted by REXML when writing a Ruby app a year ago that I switched my data format to YAML. Perl has numerous excellent solutions for XML parsing and generation, right in the standard distribution. Rubyists ported XML::Simple, but it's based on REXML, which leaves it with all the deficiencies.

A disclaimer must be made here, which also applies to the "community" section. I'm concerned mainly with the English-speaking community. For Perl, there is no other. But for Ruby, there is. Ruby is an immigrant from Japan, and has a large and vibrant Japanese community behind it. It means that there are a lot of Ruby modules without any English documentation, which is a real pity. Even if these modules are terrific, there's no way for those of us who don't understand Japanese to enjoy them.

Community

A community is extremely important in our connected age. A large, smart community means quicker answers to questions, more libraries and documentation, and just a place to share wisdom and learn new tricks.

The Perl community is just amazing. In football¹, it is often said that the home crowd is the team's 12th player. The Perl community is something like that. Perlmonks is the best programming language community on the Internet, period. Any question you have will be promptly answered by super-smart Perl hackers, some of whom seem to have little other interest in life than in providing detailed, well researched answers on Perlmonks. It's also one of the best places I know of to discuss general "meaning of life" questions in relation to programming, i.e. comparing paradigms, discussing future directions, and so on.

Ruby doesn't have anything of the kind. What it does have is a mailing list / forum / Google group². When I tried Ruby the previous time, the situation was worse – the group was less active and the connection between the various channels wasn't working well, creating fragmentation. Now, however, things seem to be better. The folks in the list are friendly and questions get answered quite quickly.

And still, Perl wins here. Someone should really create a Rubymonks – I think it would give a great boost to the community.

Momentum and future directions

This issue is difficult to define exactly, and hence I will digress to a little philosophizing. A metaphor might help. Consider two employees. One is 45, very smart, been-there done-that kind of guy. Everything he's ever done, he can do again easily, quickly and soundly. However, he's reluctant to learn new technologies, and sometime hints that he might retire early. Another is a whizzy 25 year-old. He doesn't have so much knowledge accumulated, but he's an excellent hacker and can learn very quickly. He's eager to enter any new area and signals that he'll stay in the company for a long time.

Lately, I feel that Perl is the old guy and Ruby the young guy. I will try to defend my point:

Ruby seems to be having much more momentum behind it now than Perl. New technologies are more likely to be implemented in Ruby than in Perl. New books on programming are more likely to be written with Ruby than with Perl, and most importantly, fresh hackers are much more likely to join the world of Ruby than the world of Perl.

The last point is crucial. Perl has several excellent people working with it, who are well known throughout the community. The problem is, it's pretty much the same people of years ago. In Ruby, on the other hand, names of prolific and talented hackers constantly pop up – they push the language, with its libraries and community fast forward.

For example, take the Textile markup language³. It's quite new, and it doesn't surprise me that Ruby has a better library for translating it than Perl. RedCloth, written by the amazingly prolific Ruby hacker _why supports Textile better than the best Perl library out there, and no one seems to be fixing the situation in the Perl world.

The same can be said for YAML – the parser for which was also written by _why, first for Ruby, and only later ported to Perl.

Take the bindings to Wx and Qt – the two most popular cross-platform native-looks GUI frameworks. Ruby has the better bindings for both. True, Perl's integration with Tk is unrivaled in the Ruby world, but this only proves my point – Perl is excellent in everything old, but Ruby is quickly gaining in the newer technologies. While for a GUI I'd still use Perl/Tk, I'm watching wxRuby, drooling at its pretty native widgets and controls.

I can only mention Ruby's strongest card – the Rails framework, in passing, because I have never used it.

Take alternative implementations as another example. Ruby has Rubinius, JRuby, IronRuby, Ruby.NET, what does Perl have ? JRuby and IronRuby are particularly interesting ventures, since they are backed by the enterprise. JRuby's developers were hired by Sun to create a natural binding to Java on the JVM, and IronRuby is being deveoped by, no less, Microsoft's Dynamic Language Runtime team, to bind it to the .NET framework. At last, the big two enterprise solutions – Java and .NET realized the importance of dynamic scripting languages, and did they choose Perl ? No, they chose Ruby⁴.

So why does this happen ? Why is Perl stagnant while Ruby is stronly moving forward⁵. Is it only because Ruby's core is better ? Is it because of Rails ? IMHO there's another reason, and that is Perl 6. With it hovering around, no one really wants to improve Perl 5 any more. Perl 5.5 was released one year after 5.4, 5.6 was released 20 months after that, 5.8 took 28 months, 5.10 – more than 5 years. Do you notice the tendency ?

Recall the old vs. new employee metaphor. Is Perl 6 the reason for Perl 5's stagnation – I doubt it is, but it is definitely a factor. Just how much motivation would you have working hard on somethinig you know will be thrown out soon. And now imagine this soon lasts for years and years⁶.

Conclusion

It's about time to conclude this rant. Which should I choose ? Should I replace Perl as my go-to guy with Ruby ?

The answer to this question is still no, but this time with a reservation. I enjoy writing Ruby code more than writing Perl code, at least until I ran into a piece of horrible documentation or a missing library which Perl has since 1995. But at the core, Ruby is better. And while the core is practically impossible to change (see how long Perl 6 is taking) all the peripherials are easier. In the past two years, Ruby has closed many gaps on Perl in terms of documentation, libraries and community. I think that with the current trends continuing for another two or three years, Ruby will overtake Perl in popularity and will become an all around better solution.

¹ Real football (i.e. soccer in the US).

² They're all linked. I use the Google Group interface because I find it the most convenient.

³ The one I'm using for writing this article.

⁴ Well, there's also Jython (not backed by Sun, AFAIK) and IronPython (backed by MS). But this article compares Perl and Ruby, which IMHO have a somewhat similar philosophy that is a bit different from Python.

⁵ According to the TIOBE index, Perl is currently at 5.4%, down from 8% 5 years ago, while Ruby is 2.3%, up from 0.25% 5 years ago.

⁶ Perl 6 was announced on July 19th, 2000.

DSL = Metalinguistic Abstraction

2007-07-27T14:23:26-07:00

The idea of Domain Specific Languages (DSL) has been lately brought into attention by the freshly popular programming language Ruby. In particular, the famed web framework Ruby On Rails, which is built as a DSL on top of Ruby has been a prime example.

What most people are not aware of, however, is that DSLs is just a new incarnation of the very old concept born in the world of Lisp called Metalinguistic Abstraction. It is a recurrent theme in the seminal MIT textbook, Structure and Interpretation of Computer Programs (SICP) that was written in 1985 to present general computer programming concepts using the Scheme language (member of the Lisp family).

Metalinguistic Abstraction is the process of solving programming problems by creating a new language that is better suited to tackle these problems. Unlike the traditional software engineering process of dividing problems to exactly defined subproblems and solving those subproblems, metalinguistic abstraction instructs the programmer to imagine a new programming language in which the solution of these problems can be expressed most naturally, and then implement this language.

While this sounds a bit detached, Rails actually provides a good, modern example of how such a concept can work. The designer of Rails asked himself "what language do I need to write web applications more naturally". He then went forward to implement this language on top of Ruby. Naturally, he could have created a completely new programming language. However, building it on top of an existing system provides several powerful benefits:

You don't need to craft a parser for the new language.
You don't have to make up new syntax, just use the existing syntax of the language you're building on top of.
Most importantly - since you are just building a layer on top of an existing programming language, all the facilities and power of this language are available to you, for free. This greatly enhances the immediate usefulness of the new DSL.

Ruby is a good language to build DSLs in, and Rails is a prime example of this. Ruby is better in this task than the other popular languages - Perl, Python, C++, Java, C#, etc. However, it is much inferior to Lisp. This is in no way to diminish Ruby's success or start a language war, I'm simply stating a fact. Lisp has some unique concepts that make metalinguistic abstraction natural, namely uniform syntax and macros.

Since metalinguistic abstraction is such a powerful programming technique, it is highly recommended for any programmer to learn Lisp (whether it is Common Lisp or Scheme doesn't really matter). Even if you'll never use it for any official project, just the act of learning it and understanding the programming techniques possible in it will surely expand your mind and make you a better programmer.

Logical operators in Perl and Ruby

2007-06-02T20:06:28-07:00

Both Perl and Ruby provide two sets of logical operators:

!, && and || (inherited from C)
not, and and or

Unfortunately, these two sets of operators are not isomorphic – due to differences in precedence, their semantics are different in subtle ways which make the whole issue of using them error prone. In this article I will try to elucidate this topic.

So what's the difference between them?

In order to be able to disambiguate complex expressions, parsers of programming languages assign precedence for all operators. The best known example is probably the precedence of * being higher than that of + to allow commonly understood mathematical expressions without forcing to use lots of parentheses. Another good example is the precedence of assignment being lower than the precedence of all mathematical operators. This allows statements like $a = $b + $c; to be parsed correctly without parentheses¹.

In Perl and in Ruby, the precedence of !, && and || is higher than the precedence of assignment, while the precedence of not, and and or is lower.

For example, the following code in Perl:

$a = $b || 5;

Will assign the value of $b to $a when $b evaluates to true, and 5 when $b evaluates to false (undef, 0 or an empty string). In short, it works as expected. However, the following code:

$a = $b or 5;

Is completely broken and will just generate a warning, because it is parsed as ($a = $b) or 5;.

Why the low precedence ?

As the example above shows, the low precedence of or is not such a good idea. So why was it made this way ? I think that Larry Wall wanted to make the following code legal Perl that behaves as expected:

open my $fh, "<", $filename or die $!;

Perl allows to drop parentheses where the code is not ambiguous, and proponents of the language believe it makes some code more readable. The code section above will work correctly. With ||, on the other hand, it wouldn't have worked since the precedence of || is higher than that of the comma, and the expression would be parsed as:

open my $fh, "<", ($filename || die $!);

Which isn't what we wanted. In Ruby, where code like the above is not written, this motivation plays no role.

Dealing with the confusion

So it appears Perl and Ruby have two sets of almost identical operators which behave differently sometimes. Isn't this confusing ?

It definitely is. In fact, many "good programming style" guides deal with this confusion in a very strict manner. For instance, Damian Conway's excellent "Perl Best Practices" book advises to avoid the low precedence operators at all, except for the single case of:

open my $fh, "<", $filename or die $!;

In Ruby this is irrelevant, so to extend his advice, it probably isn't recommended to use these operators at all in Ruby, is it ? I personally hold a different view.

In defence of the low precedence operators

In my opinion, the low precedence operators are better, because of two main reasons:

Not everyone came to Perl and Ruby from C and C++. On the contrary, as the time goes on, less and less people come with this background, and many start from other languages (in lots of cases, from Perl and Ruby themselves). But even for a seasoned C hacker, IMHO if not client.done? or client.result > 0 is more intelligible than if !client.done? || client.result > 0, since it is more English-like.
An important factor, at least for me, is the speed and comfort of typing on the keyboard. Typing too many punctuation characters is both slower and more stressful on the wrists. Using not, and and or wherever possible instead of !, && and || definitely helps me put as little stress as possible on my tendons.

But...

However, as we have seen, some things just can’t be done with the low precedence operators without resorting to parentheses. So for the singular case of the short-circuit assignment perhaps using || is better than or (Ruby code in this case, although it of course applies to Perl as well):

a = b || 5;

Implementing the same functionality with or feels a little superfluous:

a = (b or 5);

And || can also be used in the occasionally useful idiom²:

var ||= 5;

or has no answer in this case.

I’m sure, however, that there is much more logical condition code that short-circuit assignment code, so the low precedence operators can be used most of the time.

Another little gotcha

There is another little gotcha about low precedence operators which is mostly relevant for people with C background. or and and have the same precedence (unlike ||, which has a lower precedence than &&), so writing code like:

if cond1 and cond2 or cond3 and cond4

Won’t do what you expected. However, it is a good practice to use parentheses in all complex conditions of this kind anyway, so I don’t see it as a big problem.

Conclusion

Perl and Ruby have two sets of logical operators. These two sets have slightly different semantics, but the confusion can be avoided with a disciplined application of good programming practices. My advice is to use the low precedence operators (not, and and or) all the time. The single exception can be made in the case of short-circuit assignment, where || can be used instead of or (although or can also be used, with help from a couple of parentheses).

Footnotes

¹ Had the precedence of assignment been higher than the precedence of addition, this statement would be understood as ($a = $b) + $c;.

² This translates to var = var || 5, or “if var is defined, let it keep its value, otherwise assign 5 to it”.

irb tab completion

2007-05-07T17:49:13-07:00

irb is the interactive Ruby shell - an incredibly useful tool during development. Lisp folks are proud of the REPL (Read-Evaluate-Print Loop) - well, irb is REPL for Ruby.

What turns irb into an even more useful instrument, however, is tab completion. First, it makes coding quicker by completing known symbols (kind of an Intellisense, if you'd like). Second, and more importantly, it allows you to quickly see which methods are implemented for objects, by typing:

irb(main):001:0> some_object.

And pressing TAB twice, irb will list all the methods.

For some reason, however, irb doesn't come with tab completion out of the box. To set it up, you can create a batch file called irbb.bat, for instance, which calls:

irb -r irb/completion

And call that instead of irb. A simpler method, IMHO, is directly edit the irb.bat file in the Ruby installation bin/ directory to require irb/completion.

P.S: I describe Windows solutions. It should be very similar for Linux.

Useful resources for using YAML in Ruby

2007-04-13T15:46:24-07:00

As I mentioned here, I had a choice of using either XML or YAML for the configuration files in the new version of ESMS. YAML won for two reasons:

It is much more lightweight and looks natural. Big configuration files in XML become complex and cluttered, while YAML scales admirably in this respect.
The current de-facto XML implementation in Ruby is REXML, which I dislike. REXML is useful for employing XML as a serialization format, but is less good as a configuration file reader, because its error handling is very bad. On the other hand, Syck (the built-in YAML parser / emitter in Ruby) is easy to use, fast and has good error handling and reporting.

The following are good resources for YAML in Ruby:

Yaml cookbook - shows probably all you'll ever need to understand how Yaml entities map to Ruby code. Very useful.
Yaml.rb docs - A reference manual with examples for the Yaml.rb library.
YAML specification - from the official YAML website (yaml.org). A crisp yet well written reference to the YAML syntax and semantics.