

Ask HN: Why do people consider Ruby better than Perl or vice versa? - budwin

I've seen a lot of anti-perl, pro-ruby speak recently on HN and am curious for what reasons people find Ruby to be superior (esp. from people who have experience with both)<p>I'm personally a fan of both (and continuously delighted by learning new things in both languages). I'm spending more time with Ruby lately because it looks like it's where the community is going and is fashionable these days, but I have no real major issues with perl itself.<p>Perl is often a stereotyped as unreadable, but it's largely up to the writers of the code itself to make it _that_ illegible; it's not a consequence of the language.
======
jordandanford
I tried both for a while when I was getting into programming, and one huge
thing that has always bothered me about Perl is the strange behavior with
changing sigils. Here's what I mean:

$foo is a scalar

@foo is an array

$foo[0] is the first element of @foo, instead of @foo[0]

As far as I know, Larry Wall's rationale as a linguist was that in English,
one would say "this apple" and "these apples", but "this third apple" instead
of "these third apple". The problem is that code isn't a human language, and
obeying these rules doesn't make sense and puts additional cognitive strain on
the programmer. Basically, having different syntax quirks for scalars, arrays,
hashes, and file handles makes code unnecessarily weird, especially when
combining them for things like multi-dimensional arrays.

~~~
matt_p
Why is this difficult to understand? my @foo = qw(1 2 3); $foo[0] = 1;

you are referencing an array and returning a scalar. the sigil represents a
scalar which is what is returned. A list isn't being returned, so why should
the sigil represent that?

~~~
aaronblohowiak
Why require context-dependent sigils when you don't need to?

Eliminate the unnecessary.

~~~
phamilton
for the same reason strcmp() returns not just a -1,0, or 1, but a "distance"
between the two strings being compared. A function or syntax has multiple uses
if additional information is available to the programmer.

Example:

@array = qw(1 2 3); $length = @array;

print $length;

By allowing a non scalar to take an implicit scalar form, we have an extremely
useful and quick way to get the length of an array. Nothing that difficult to
replace with a len() call, but it's language features like these that make
perl ($length = @_ may be the most useful of all) so handy for quick hacks.

~~~
jordandanford
I guess my problem with something like that is that conceptually it doesn't
make much sense. There's no obvious reason why assigning an array to a scalar
variable would give its length – it doesn't really feel clear or elegant, just
unexpected.

------
ludicast
I believe the Ruby community is very pro-Perl. I enjoyed Perl myself and Ruby
seems to have a lot of the same soul to it.

I usually say Ruby is everything I loved about Perl with none of what I
disliked/hated.

~~~
sabat
I'm an old Perl hacker but do most of my work in Ruby these days -- and love
it. I'll always have a soft spot for Perl, and will never forget how it helped
build the Internet. But to me, Ruby makes Perl look like Java.

~~~
rbrcurtis
Can you explain the "makes perl look like java" comment? how does perl look
like java?

~~~
sabat
I'm kind of kidding, but Ruby lets you do things more elegantly than you can
in Perl, and with less verbosity (hence the Java comment). It's really a
syntax issue that I'm talking about, but it matters a lot for readability and
language usability.

Perl:

my $x = 'Apple Carrot Banana';

# sort them into an array

my @y = sort split(' ', $x);

# do we have more than 2 elements? (just a random test)

if (scalar(@y) > 2) {

    
    
      print "we've got ", scalar(@y), " elements!\n";
    

} else {

    
    
      print "insufficient elements. fail.\n";
    

}

Ruby:

x = 'Apple Carrot Banana'

y = x.split(' ').sort

if (y.size > 2)

    
    
      puts "we've got #{y.size} elements!"
    

else

    
    
      puts 'insufficient elements. fail.'
    

end

Ruby just seems more elegant to me, more programmer-friendly. YMMV.

~~~
chromatic
A modern Perl programmer might write something much more elegant:

    
    
        my $x = 'Apple Carrot Banana';
        my @y = $x->split(' ')->sort;
    
        if (@y > 2) {
            say "we've got ${\@y->size} elements!";
        } else {
            say "insufficient elements. fail.";
        }

~~~
colomon
Or ever-so-slightly lighter Perl 6 version:

    
    
        my $x = 'Apple Carrot Banana';
        my @y = $x.words.sort;
    
        if @y > 2 {
            say "we've got {@y.elems} elements!";
        } else {
            say "insufficient elements. fail.";
        }

------
spooneybarger
I've used perl for over 15 years and ruby for over 5.

I prefer ruby just because, I tend to be able to read and understand other
people's ruby code easier than other people's perl code.

Maybe that is something about the language, maybe it is something about the
people who use each, maybe it is something about their cultures or something
about me. In the end it doesn't matter much to me.

~~~
nolite
Other people aside.. I prefer ruby because I tend to understand my own code
easier when coming back to it. Every time I try working with Perl, I have to
"relearn" the language

------
martinp
Ruby owes much of its popularity to Ruby on Rails. I don't think Ruby would be
as popular (or "hip") if it hadn't been for Rails.

Ruby on Rails also appeared around the time webapp development was gaining a
lot of momentum, so that might be a part of the reason.

I myself don't find Ruby superior, for me Ruby (on Rails) and Perl solve
problems in different domains. Ruby is great for web development. Perl is
great for system administration and scripting, and it's preinstalled on most
Unix-like systems (although Python has replaced Perl for the most part in my
case).

------
bradleyland
Anti-perl speak? I must have missed it. I'm not sure why someone would hold a
poor opinion of perl, unless it were simply personal taste. To say you don't
like a language is not the same as saying a language is bad. I don't like to
program in ASP.NET C#, but I don't think it's a bad framework/language.

Perl is kind of the "C of scripting languages". It's been around for a very
long time (late-eighties/early-nineties). The fact that modern languages, like
Ruby, borrow from a language that was invented in the late-eighties says a lot
about that language.

~~~
byoung2
_Perl is kind of the "C of scripting languages". It's been around for a very
long time (late-eighties/early-nineties). The fact that modern languages, like
Ruby, borrow from a language that was invented in the late-eighties says a lot
about that language._

Perl seems like such an old language...it's hard to believe it's only been
around 23 years. It goes to show you how quickly things change in the tech
world.

------
huxley
What you are seeing is probably more sibling rivalry (or plain old fanboyism)
than genuine hatred.

From the Ruby FAQ:

"If you like Perl, you will like Ruby and be right at home with its syntax. If
you like Smalltalk, you will like Ruby and be right at home with its
semantics. If you like Python, you may or may not be put off by the huge
difference in design philosophy between Python and Ruby/Perl."

<http://www.rootr.net/rubyfaq-2.html>

~~~
huxley
But to the question of whether a language can be intrinsically "illegible",
I'd say that it is easier to write "hard-to-read" code in some languages than
others.

The conventions that a language community shares often lead to easier or
harder to read code. In the Perl community, clever code which solves a problem
is highly valued. In the Python community (as the Python Cookbook famously
says) "To describe something as clever is NOT considered a compliment in the
Python culture." A Pythonista is more likely to compliment your clean code, to
say that it is pythonic.

I don't know enough about Ruby's community to say whether they have their own
view about the relative merits of the clever/clean approaches or if they value
something else entirely.

~~~
mishmash
> I don't know enough about Ruby's community to say whether they have their
> own view about the relative merits of the clever/clean approaches or if they
> value something else entirely.

Although I think some groups are starting to pick up an anti-clever view of
these (the Merb movement probably helped), but you can almost pick any random
ruby github project and there will be some custom magic under the hood.

Not saying that's good or bad, just sayin.

~~~
perigrin
The Perl community has a strong movement of anti-clever, or at least "clever
as a last resort" these days. Much of the Modern Perl movement is based upon
being solidly engineered over shiny and polished. Take for example Moose's
stated policy of prioritizing Correctness over everything else.

------
mopoke
People naturally compare Ruby and Perl because of the well-known similarities
and influence that Perl had on the development of Ruby.

Ruby followers can rightly claim advantages over Perl (for me, the fact that
you can do OO in Ruby without feeling that you're doing some kind of black
magic is the big one).

But Perl devs could be justified in feeling that Ruby is doing nothing new -
many of the libraries that make Ruby so useful have equivalents (predecessors
in some cases) in Perl.

------
cgrubb
Switched from Perl to Ruby in 2006. Things I like off the top of my head:

One variable type. This makes references unnecessary. Also, everything that
can be stored in a variable is an object.

I can remember the Ruby syntax for defining a class. In Perl I had to look it
up every time. Also Perl has two competing class systems.

Methods by default take a fixed number of arguments and there are no implicit
conversions between strings and numbers. This catches a lot of errors.

Good Perl practice involves boilerplate such as 'use strict'. I hear about
lint tools and such and it makes me think the situation has gotten worse since
2006.

The Ruby Array class and the Enumerable module are good. I've become dependent
on methods that aren't as readily available in Perl: include? each_with_index
all? any? permutation. Also the intersection and union operators: & and |.

Ruby blocks.

Ruby 1.9 has the Fiber class (rough equivalent to Python generator).

Ruby IO operations throw exceptions when they fail. Hence you don't need the
'|| or die "could not open!"' idiom.

~~~
perigrin
A lot of your points I'll concede are probably better in Ruby. At least
they're defaults in Ruby, while the solutions in Perl exist on CPAN (AnyEvent
and POE for example for solutions similar to Fiber exit on CPAN but not in
core).

However either you've totally missed the last four years in Perl. Perl has
been challenged by Ruby, Python and Perl6. Because of this we've had a lot of
developments that you gloss over or ignore.

> I can remember the Ruby syntax for defining a class. In Perl I had to look
> it up every time. Also Perl has two competing class systems.

The Perl Syntax for defining a class is pretty straight forward. I'm awfully
sure I haven't had to look it up in a decade:

    
    
        package Foo;
        sub new { my $class = shift; bless {}, $class }
        1;
    

I'm not sure what the "competing class" system you're referring to is though.
Perhaps you mean Moose (first released in 2006 when you left). The assumption
that it is "different" is incorrect because Moose does roughly the above,
except the `new` method is inherited from a base class. The Moose syntax here
is:

    
    
        package Foo;
        use Moose;
        1;
    

Given the Moose syntax, I'm not sure what is harder to remember than Ruby's
syntax:

    
    
        class Foo
        end   
    

Additionally there is MooseX::Declare which hacks the Perl parser/tokenizer to
allow new keyword syntax (a feature added to core 5.12) allowing you to say:

    
    
        class Foo { }
    

> Good Perl practice involves boilerplate such as 'use strict'. I hear about
> lint tools and such and it makes me think the situation has gotten worse
> since 2006.

Yes it is unfortunate that Larry didn't predict what the good defaults would
be in 1987 (Perl1) or 1994 (Perl5). With Perl 5.12 good Perl practice
involves:

    
    
        package Foo;
        use 5.12;
    

I'm not sure that this is necessarily "worse" than 2006's:

    
    
        package Foo;
        use strict;
        use warnings;
    

It is 2/3rds of the line count, but really we're talking about _one_ line.
Additionally I'm a _very_ active member of the Perl community and I haven't
heard about "lint tools". Perhaps you mean `perltidy`? This isn't a lint tool,
it's a source code beautifier ... like html-tidy.

> Ruby IO operations throw exceptions when they fail. Hence you don't need the
> '|| or die "could not open!"' idiom.

You can use the (now in core) `autodie` pragma to eliminate this idiom from
Perl too. Yes it's unfortunate that the idiom could spread for the first 20
something years of Perl making the nearly-anal-backwards-compatible defaults
not enable it.

> The Ruby Array class and the Enumerable module are good. I've become
> dependent on methods that aren't as readily available in Perl: include?
> each_with_index all? any? permutation. Also the intersection and union
> operators: & and |

These exist on CPAN in various modules. List::Util, List::More::Util etc. Yes
it is unfortunate that they're not more easily available. This is part of the
price paid to backwards compatibility demons and keeping the Perl standard
library (relatively) small.

------
tlrobinson
_"Perl is often a stereotyped as unreadable, but it's largely up to the
writers of the code itself to make it _that_ illegible; it's not a consequence
of the language."_

Well, one argument is that the language (and community) should encourage
good/readable/maintainable code.

~~~
perigrin
I'd argue that the community by and large has for at least the last 5 years.
Starting in 2005 with Damian Conway's _Perl Best Practices_ and the tools like
Perl::Critic that came out of it. Add to that tools like `perltidy` (that was
recommended strongly in Damian's book), a strong testing culture (see other
threads on HN which discuss the automatic testing of _all_ modules on CPAN),
modern changes like 5.12 enabling `strict` and `warnings` pragmas by default.
Additionally tools like Moose simplify and reduce the boiler plate associated
with traditional areas of Perl's ... shall we say extended obtuse verbosity
... namely Object Oriented programming.

By and large Modern Perl code is strongly encouraged to be readable,
maintainable with a sound well engineered basis. If someone is telling you it
isn't, they haven't paid attention for half a decade.

