From: Robert Klemme <shortcutter@...>
Date: 2008-06-05T05:59:14+09:00
Subject: Re: A crosspost from the Perl Community

On 04.06.2008 19:20, Star Cross wrote:

> I've been thinking of myself as a Perl developer for the past several
> years, and recently was handed a Ruby project. I collected some of my
> thoughts on the experience for PerlMonks, and it was suggested that I
> cross post in a Ruby forum to see what sorts of responses the other half
> might have to offer.
> 
> Seeing as how I found Ruby to be a good language that I anticipate using
> in the future, I think it's a good idea, and so I offer it below:

Thank you for sharing this!

> I don't mean this to be a exhaustive list of differences, a detailed
> technical comparison, or an introduction of Ruby for Perl programmers.
> Just a gathering of thoughts that I feel the need to share.

I will try to comment in that very spirit because you triggered some 
interesting thoughts about the two languages.

> 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.

I find a poorly indented application hard to read in *every* programming 
language.

> 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.

I am not sure I get your point here: if _statement_ separators are not 
used they do not clutter.  How does this *option* remove the benefit of 
readability?

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

Well, you can probably do this with every language. :-)

> From this Perl programmer's perspective, it takes some getting used to.
> Instinctively one wants to write
> 
> _Perl Code_
> foreach my $member @array { ... }
> 
> rather than
> 
> _Ruby Code_
> array.each { ... }

If you like you can as well do

for member in array
   ...
end

> --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.

My Perl has become a bit rusty over the years with Ruby but I tend to 
find it difficult to find my way through $, ->, % and combinations of 
those if I look at a Perl program these days.  I definitively feel more 
comfortable with the Ruby way which is probably also a matter of what 
you are used to.  Maybe you could put it this way:

A Ruby programmer is more interested in what is done with an object (aka 
which methods are invoked) whereas a Perl programmer is more focussed on 
the type of data.  (Digressing a bit here to a topic that may be 
related: I have the impression that when writing Perl programs people 
usually use nested structures of arrays, hashes and scalars to represent 
complex data whereas in Ruby land people - at least I - tend to rather 
create classes and use them because it is so much easier than in Perl. 
This gives you the additional benefit of encapsulating methods with the 
data whereas in Perl you have to write functions for this type of data 
structure.  For me the Ruby way is easier and also easier to maintain, 
but then again I might not have been a good Perl programmer.)

Also, if you write OO programs this distinction goes away in Perl as 
well IIRC.

> Ruby doesn't use this convention, and boy did I miss it. The @ character
> makes an appearance to signify a class variable, but that's it.

@ signifies an instance variable, whereas class variables are prefixed 
with @@ (but rather not use them as their scoping is a bit weird and can 
easily lead to strange bugs).  If a @variable is a member of a class 
then it is sometimes also called "class variable" although I believe the 
more appropriate term would be "class instance variable".  Then we also 
$global_variables.

> 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.

I have the impression that in the Ruby community this is rather seen as 
an advantage (-> duck typing).  In other words you can exchange a Hash 
or anything else that supports #[] for an Array easily.  So there are 
definitively two sides to this coin.

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

That may be true on the statement level, but I find it easier to 
identify the structure of a Ruby program.

> --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.

Just for the sake of completeness: there is also RAA although it is 
probably not as complete as CPAN.
http://raa.ruby-lang.org/

> This is, I think, a reflection of the relative maturity of Perl to Ruby.
> With a decades long 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.

There is at least a very active (and friendly) community accessible 
through web forum, mailing list and usenet.  Often answers come pretty 
fast, too.  As far as I can see from the PerlMonks FAQ(*) ruby-talk 
serves the same purpose although I cannot reasonably compare them as I 
have 0 knowledge of PM.

* http://perlmonks.org/?node_id=243870

> --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.

I did not know that.  Actually I cannot remember that the topic of 
integrating Perl and Ruby came up on ruby-talk; it's probably very 
infrequent.

> 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.

Absolutely agree.

> 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.

My mileage varies but I guess that is just a matter of personal taste 
and experience.

However, there is one thing that you did not mention and that can be 
said in favor of Perl because it sometimes matters: runtime performance 
of Perl programs is often better than that of Ruby programs.

Kind regards

	robert