Asp Forum - A crosspost from the Perl Community

Star Cross

6/4/2008 5:21:00 PM

All,

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:

------

A recent project I've been working on has brought me into more intimate
contact with the Ruby programming language than I have had before, and
as I take a moment to return to maintaining some Perl apps I've written,
I thought I might share some of the the thoughts that came into the head
of this Perl programmer as he delved into Ruby for the first real time.

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.

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

_Perl Code_
foreach my $member @array { ... }

rather than

_Ruby Code_
array.each { ... }

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 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 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.
<P>
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--
* http://use.perl.org/~jmcada/jou...
* Thomas, Dave. "Programming Ruby, The Pragmatic Programmers' Guide."
Pragmatic Programmers, LLC. Raleigh, 2005.
* Introduction to Ruby for Perl Programmers

Originally posted on PerlMonks at http://perlmonks.org/?node...
--
Posted via http://www.ruby-....

54 Answers

David Masover

6/4/2008 7:48:00 PM

On Wednesday 04 June 2008 12:20:37 Star Cross wrote:

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

Very true. But can you make Perl as pretty as Ruby?

Every language can be made messy. Not every language can be made clean.

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

Until you start working with objects. Then everything's a scalar:

$myobject->{some_value}
$myobject->method_a()->method_b()

At this point, the only advantage of $ is that it's easier to tell that this
is a variable, and not a command. This distinction isn't as useful in Ruby, I
think, because of how easy it is to use accessors -- at which point, you
don't need to know if it's a variable or a method.

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

Actually, there's also $ for globals, and captialization for Constants.

> The fact
> that hashes and arrays are both indexed using square brackets ([])
> contributes to the confusion.

In Perl, I often fell into the trap of naming several variables the same
way -- I would have two or more of:

@foo
$foo
%foo

So, while it's not quite as concise, if there's ever confusion, I will name
things appropriately.

There's also the fact that I can't remember the last time I accessed an array
with the [] notation. Most often, it's through things like <<, each (and
other iterators like inject), and +.

While I'm at it, one thing I do miss from Perl is variable declarations being
enforced with 'use strict' -- in Ruby, the lack of this means that
misspelling a variable name could lead to a much subtler error than "requires
explicit package name".

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

It's worth mentioning that their respective infrastructures (rubygems vs CPAN)
are at least comparable, technically. As far as I know, Python's equivalent
isn't.

And it's not often these days that I can't find something I need as a gem, and
it exists as a CPAN module. Maybe that reflects my own inexperience, though.

It's also a fundamentally different community, I think -- it exists largely in
blogs. When I had a question about how to do something in Perl, I'd most
often look on CPAN and find it already done, with good examples in the
documentation. When I have a question about how to do something in Ruby, I
use Google, and almost always land on someone's blog.

Good post, though. I, too, knew Perl long before I knew Ruby, and I drift back
and forth over time.

Roger Pack

6/4/2008 8:01:00 PM

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

Yeah some people consider it a 'feature' that you don't know what you're
dealing with, only that it quacks like a duck. One thing you can do
[and no one does] is name your variables, like i_count i_number.
I'll just go ahead and say it, though. when I look back at perl code
the first that strikes me is that it hurts my eyes to see all those $'s.

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

Yeah Ruby just doesn't seem to have tons and tons of community. Not
yet, at least. Ex: developing core things, like the GC, or porting
things to mingw. If you ever want to feel alone...
That being said for normal ruby stuff there's not tons of support but
you CAN just hack what exists and come up with acceptable solutions, and
submit a patch [and it usually doesn't hurt too bad]. Now that is nice.
Probably also possible in perl. So they're similar :)
-R
--
Posted via http://www.ruby-....

Phillip Gawlowski

6/4/2008 8:23:00 PM

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Roger Pack wrote:
|> 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.
|
| Yeah some people consider it a 'feature' that you don't know what you're
| dealing with, only that it quacks like a duck. One thing you can do
| [and no one does] is name your variables, like i_count i_number.

int[] numbers; //straight from MS's C# tutorial on Arrays
byte[] number; // Contrived example on my part.

Do you remember that numbers is an array of integers 10 LOC later? What
about 100 LOC? Do you remember that number is an Array of bytes?

The issue you describe is not an issue of a broken tool or feature. But
a lack of naming conventions, as you said.

Oh, and in your example: does 'i' signify 'integer' or 'input'? ;)

- --
Phillip Gawlowski
Twitter: twitter.com/cynicalryan
Blog: http://justarubyist.bl...

~ It seems like once people grow up, they have no idea what's cool.
-- Calvin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail....

iEYEARECAAYFAkhG+fsACgkQbtAgaoJTgL8lOACfSaEF1i79PG+cFT2HFCgY4w2h
etYAnjQ6mOjEyI6wylTlpvVzCJJAZifP
=aKhH
-----END PGP SIGNATURE-----

Robert Klemme

6/4/2008 8:56:00 PM

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

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

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

Jano Svitok

6/4/2008 9:45:00 PM

On Wed, Jun 4, 2008 at 10:00 PM, Roger Pack <rogerpack2005@gmail.com> wrote:
> I'll just go ahead and say it, though. when I look back at perl code
> the first that strikes me is that it hurts my eyes to see all those $'s.

The funny thing is that this was my feeling about ruby back when I was
a python guy.
I heard that it's a nice language, but anytime I saw those @ and $ I
turned back.

Apparently that time I preferred self and __init__ to @s and $s. Now
it's the other way round.

J.

Siep Korteling

6/4/2008 10:17:00 PM

Star Cross wrote:
(...) and as a result, when I'm presented with a
> task that seems unusual, awkward, or that requires fitting fitting the square
peg in the triangular hole, Perl will continue to be the natural choice.
>
>
> Originally posted on PerlMonks at http://perlmonks.org/?node...

I learnt both languages more or less simultaneously. Learning ruby meant
(re)thinking OO, learning Perl meant learning syntax. Ruby's syntax
suits me far better. In Perl, I never get it right the first time (nor
the second time); in ruby sometimes dozens of LOC will just run.
On the other hand, the few times I used some of Perl's CPAN modules, I
found they are indeed well designed, well documented and a breeze to
use.

So, if a triangular peg in needs to be put in a triangular hole, I'll
happily resort to Perl if I can't get it to work with ruby.
If a square peg needs to be put in a triangular hole however, I prefer
ruby (and a hammer).

regards,

Siep
--
Posted via http://www.ruby-....

Arved Sandstrom

6/5/2008 12:39:00 PM

"Star Cross" <starx@axisoftime.com> wrote in message
news:35db1cb396d98e77362722b737b4ccf5@ruby-forum.com...
> All,
>
> 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:
[ SNIP ]
> --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.
[ SNIP ]

Good post. I too am Perl first, having started with Perl 4 back in the early
'90's. Perl really set the tone for infrastructure - you mention CPAN, but
POD and the classic mechanics of Perl modules also stand out.

I'd agree with you, having started to use Ruby some in this past year or so.
For OOP I think I'd go with Ruby. Interestingly enough I do not believe I
would have adopted this viewpoint until having used "clean" OOP languages
like Java or C#...Perl 5 was my second OOP language after C++ (well, really
the third if one considers Prograph), and so after C++ I certainly didn't
think of Perl OOP as being particularly cumbersome. :-)

For most scripts I'd still use Perl. A matter of familiarity more than
anything else.

AHS

Dave Bass

6/5/2008 3:01:00 PM

Coming to Ruby recently from Perl, these are my comments.

Star Cross wrote:
> 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*.

All languages are different. You soon get used to it! From someone who
cut his teeth on Fortran IV, Ruby's layout doesn't look too bad.

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

Ruby is much more OO than Perl. I started with Perl 4.036, which had no
objects, then Perl 5 really had OO kludged onto it in a nasty way. In
Ruby, everything is OO. (This is much nicer than Java, which I've also
used.)

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

Ruby has a different model. In Ruby, variables are *references* to
objects. So an array variable is the same as a hash variable etc:
they're all just references to objects. In Perl, references are all $
variables, so it's no different really. (One can easily devise a naming
system to help you remember what everything is, if necessary.)

You can get bitten by this. Everything is call-by-reference, not
call-by-value as in Perl, C etc. Change a function's parameter and you
change the original, not a local copy of it.

> The fact
> that hashes and arrays are both indexed using square brackets ([])
> contributes to the confusion.

No, they're both arrays; it's just a question of whether they're ordered
and indexed by integers (like Perl arrays), or unordered and indexed by
whatever you like (like Perl hashes). The square brackets consistently
denote indexing.

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

I find the contrary. Uncommented Perl is typically impossible to
understand unless you wrote it yourself. It *is* possible to write clear
Perl but, as with C, most people don't bother.

> Ruby has test/unit.

Much much better than anything I've used in Perl. Test/unit makes
test-driven development a breeze. Best thing since sliced bread!

> That said, I've always believed that the strength of any organization is
> in its people.

It's the language I'm interested in, not the people. That's why I went
into engineering rather than social work or politics! ;-)

--
Posted via http://www.ruby-....

Eric Mahurin

6/5/2008 3:35:00 PM

On Thu, Jun 5, 2008 at 10:00 AM, Dave Bass <davebass@musician.org> wrote:
> You can get bitten by this. Everything is call-by-reference, not
> call-by-value as in Perl, C etc. Change a function's parameter and you
> change the original, not a local copy of it.

No, ruby is still call-by-value. The "value" is an object reference
(or simply an object in ruby terms). If the object is mutable, then
a function can modify it. Call-by-reference on the other hand refers
to passing an lvalue reference. If ruby had call-by-reference, you
could pass an lvalue (something that can be on the left side of an
assignment) and when the function modified the corresponding argument
variable, the lvalue would change (not just the object that the lvalue
has).

Perl actually does have call by reference. The items in @_ for a sub
can be lvalue references and changing them changes the callers lvalue.
But, most start a perl sub with something like this copies that
values (losing the references):

my($a, $b) = @_;

C++ can also call-by-reference and C can emulate it (with pointers to lvalues).

With a bit of work you can also emulate call-by-reference in Ruby.
Here's an example using simple lambdas:

def swap(get0, set0, get1, set1)
tmp = get0
set0[get1]
set1[tmp]
end

a = 1
b = 2

swap(lambda{a}, lambda{|v| a=v}, lambda{b}, lambda{|v| b=v})

Eric Hodel

6/5/2008 8:08:00 PM

On Jun 4, 2008, at 10:20 AM, Star Cross wrote:

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

I no longer think this way about programs I write. Enumerable and
block argument multiple assignment allow you to not care about what
type of object is on the left hand side. Instead you can use friendly
variable names to make your code very readable.

An arbitrary example would be:

meetings = {
'eric' => ['thursday at 1100', '206-555-0000']
'ryan' => ['thursday at 1300', '206-555-0001']
}

meetings.each do |callee, (time, phone_number)|
puts "call #{callee} at #{time} on #{phone_number}"
end

comp.lang.ruby

A crosspost from the Perl Community