One of the most important design decisions in ruby is that everything is an object and practically everything you can do with those objects is implemented as a method call, in fact, a lot of the functionality that in perl is implemented as operators and functions are just method calls in ruby:

container.each { |element|
   # do something with element
}
[download]

Is more or less equivalent with

foreach my $element (@container) {
  # o something with $element
}
[download]

Except that every container can decide how to implement its each method, which means you can keep the ruby code exactly the same if you decide to switch from a standard array to another implementation (like requesting records from a database, or reading lines from a filehandle etc etc) *)

Compared to perl, ruby makes extensive use of polymorphism, and less auto-conversion of objects. For instance, a "+" operator will concatenate strings and add numbers in ruby **) while in perl "+" will convert strings to numbers and add them - this is one of the reasons perl has so many operators: since they force conversions on their operands, you need "+" and ".", "*" and "x" etc. This difference will be even more apparant in perl 6.

One of the advantages of doing it the way perl does, is that it takes less typing; you almost never have to explicitly convert from strings to numbers or back. One of the advantages of doing it the way ruby does, is that it keeps the basic language simpler (less operators) and if the API is good it can make it easier to inject your own object types into existing code/library calls. Also IMHO ruby's way scales better. See the container.each example above.

Also, ruby has stable, light-weight multithreading compared to perl. This is, at the moment, my biggest reason for using ruby instead of perl for some programs - you can quite easily run a program with 200+ threads in ruby, while in perl, using 200 threads or forking 200 sub-processes tends to slow things down too much.

If you want to know more, I suggest you get a good book on ruby; I like the pickaxe book. I have the second edition in paper, but the first edition is also freely available online.

*) Yes, you can tie an object to an array in perl, but that's not quite the same thing.
**) Note that in ruby, 1 + "a" is an error.

I was impressed with a different benchmark, posted here in PM some time ago, that showed that Ruby generally has shorter source code for the same problem, with similar performance to Perl. I was further impressed with how quickly Ruby built when I downloaded and installed it. Unfortunately, I haven't had time to get into programming Ruby. It seems to me that Perl, Python, and Ruby all fill roughly the same niche. Preferences are generally based on style.

His Perl could have been tightened up considerably.

Boy, is that a call to action! I can't believe I'm the first in 4 years to have taken it up …. Here's a more-or-less faithful copy:

use strict;
use warnings 'all';
use constant {
    EMAIL => 17,
    CONTACTME => 27,
    SKUTITLE => 34
};


my @records; # Arrays are initialised empty; no need to do it explicit
+ly.

push @records, [ split "\t" ] for <>;
do { tr/"//d for @$_ } for @records;

my @contact_records;
do { push @contact_records, [ @$_[ SKUTITLE, CONTACTME, EMAIL ] ] if $
+_->[CONTACTME] == 1 } for @records;

{
local $, = "\t";
local $\ = "\n";
print @$_ for sort { $a->[0] cmp $b->[0] } @contact_records;
}
[download]

To me, this task suffers, rather than benefits, from the names, and is much better suited for a Unix-style pipeline; fortunately, Perl is good at those (although I resort to substr to avoid the to-me unsatisfying s///; $_):

use strict;
use warnings 'all';
use constant {
    EMAIL => 17,
    CONTACTME => 27,
    SKUTITLE => 34
};

{
local $, = "\t";
local $\ = "\n";
print @$_ for
    sort { $a->[0] cmp $b->[0] }
        grep { $_->[1] }
            map {
                chomp;
                [
                    map { substr $_, 1, -1 }
                        ( split "\t" )[ SKUTITLE, CONTACTME, EMAIL ]
                ]
            } <>;
}
[download]

I've replaced the test for whether the CONTACTME field == 1 (not eq "1", ugh) with a test for whether it's true, since that's almost certainly what was meant; but it's easy to change it back.

Finally, note that, since the CONTACTME field is not carrying any useful information, we might as well avoid printing it; so we could define

sub snip_or_toss { $_[CONTACTME] ? @_[ SKUTITLE, EMAIL ] : () }
[download]

replace the outer map by map { chomp; [ map {...} snip_or_toss split "\t" ] }, and then get rid of the grep.

If you're asking about the size of the user community and the freely available resources, there is no comparison. Despite the frequent blog postings, Ruby's user base remains very small. Perl is one of the most popular languages in the world, and CPAN is very large and useful. Some people may find Ruby's features more interesting, but it's still just getting started in terms of relative usage and the maturity of its CPAN-equivalent.

Which isn't to say that Ruby isn't ready to be used in the real world.

While the Ruby community is smaller than Perl's, it's active and helpful so you can get questions answered and problems solved.

Ruby itself has been around for a fair number of years and has been beaten up enough to have the rough edges knocked off. It's stable and works well in my experience.

RubyGems et al aren't as expansive as CPAN, but for a lot of the stuff I do it's reached the stage where the more complicated bits of what I need come off the shelf.

To be honest the only things I really miss in Ruby are the attention Perl module authors pay to documentation, I spend too much time in Ruby reading code, and Perl's testing framework. TAP and the Test:: modules rock :-)

One thing I miss is the amenities to reduce the amount of quoting the user has to do when using hashes. Compare:

h = {"one"=>1, "two"=>2, "three"=>3 }
h["four"] = 4
[download]

to this in perl:

%h = (one=>1, two=>2, three=>3);
$h{four} = 4;
[download]

You can tell perl was written by a linguist -- there's more interest in making the language expressive, with natural shortcuts, rather than "pure."

Being able to convert input strings to numbers instantly is another nice shortcut. "Everything's an object" gets in the way of that in ruby.

The worst thing is the complete lack of a protective mode like "use strict;" as I discussed here. Writing in ruby feels unsafe to me.

Perhaps I am spoiled by some of the features in perl. If I had started first with ruby I might like it better.

h = {"one"=>1, "two"=>2, "three"=>3 }
h["four"] = 4
[download]

Then again in most Ruby code it would be more idiomatic to use symbols instead of strings as the keys so it would come out as:

h = {:one=>1, :two=>2, :three=>3 }
h[:four] = 4
[download]

which rolls off the fingers quite nicely in my opinion.

You can tell perl was written by a linguist -- there's more interest in making the language expressive, with natural shortcuts, rather than "pure."

Then why do I end up typing less when I use Ruby? :-)

Some things are shorter in Ruby than Perl. Some things are shorter in Perl than in Ruby. I certainly don't find Ruby more verbose than Perl. The opposite if anything.

Being able to convert input strings to numbers instantly is another nice shortcut. "Everything's an object" gets in the way of that in ruby.

It's not the everything-is-an-object bit of Ruby that gets in the way. Everything is an object in Perl 6 and it keeps the auto-conversion between numbers and strings.

It's a design decision on how those objects behave. For me it's six of one and half dozen of the other - neither option makes a huge difference to the way I code.

The worst thing is the complete lack of a protective mode like "use strict;" as I discussed here. Writing in ruby feels unsafe to me.

I have to admit that I too thought that this would be a problem, but I've found this a complete non-issue when using Ruby.

Then, why do you worry?

Yes, Ruby has some very nice features. So does Javascript. I personally like Javascript's OO features better than Perl's, and it treats functions as first-class datatypes (which Perl doesn't). So ... should we all use Javascript now?