Ask HN: Why do people consider Ruby better than Perl or vice versa? | Hacker News Reader

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

12 pointsbudwin28 comments

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)

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.

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.

View on HN

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.

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?

I understand the idea behind it, but I don't feel like it's any clearer than "foo = [1, 2, 3]; foo[0] = 1" (in Ruby, Python, or something similar). This was even changed in Perl 6 because the different sigils just increased obfuscation: http://en.wikipedia.org/wiki/Perl_6#Sigil_invariance

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

Eliminate the unnecessary.

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.

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.

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

That's a circular argument. So is "Why not require them when you need them?"

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.

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.

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

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.

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.";
    }

And one that doesn't like autobox would say:

    use 5.12.2; # enables modern features
    my $x = 'Apple Carrot Banana';
    my @y = sort split ' ', $x;

    say @y > 2 ? "we've got ${\scalar @y} elements!" 
               : 'insufficient elements. fail.';

Not everything needs to be an Object. Not every call needs to be a method call. Some people think better with procedures, some people think better with objects.

One of the reasons I personally like Perl is I can use which ever one is appropriate to the problem domain.

Edit: forgot the `sort` call.

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.";
    }

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.

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

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

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.

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.

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

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.

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

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.

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.

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.

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.

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

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.

Reply on news.ycombinator.com