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.
$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.
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?
Eliminate the unnecessary.
I usually say Ruby is everything I loved about Perl with none of what I disliked/hated.
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."
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.
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.
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.
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.
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.
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.
Well, one argument is that the language (and community) should encourage good/readable/maintainable code.
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.
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).
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.