Slashdot Mirror


Ruby-Is it Prettier than Perl?

Kailden asks: "I've run across several references to Ruby, a scripting language that claims to be a hybrid of Perl and Python. Supposedly, this language has taken Japan by storm. I'm looking for Slashdot's verdict before jumping in. Has anyone outside the Ruby site used this language? What advantages/disadvantages have you found?"

2 of 19 comments (clear)

  1. It had to happen by drix · · Score: 3
    I'm not too shocked. It's not really a big secret that Perl OO is pretty ugly as it stands now; it's much like C++ is to C in that OO support was kind of welded onto the side as an afterthought. Someone looking to satiate the PHBs of the world who think OOP is the greatest thing since sliced bread had to do it sooner or later. But whether it's a good idea or not remains to be seen.

    My issue with ruby is this: OOP just doesn't work for a lot of Unix programming situations. It's not a conincidence that 95% of all Unix apps are still written in C, despite it's successor having been around for 20+ years. Procedural programming is a lot less convoluted, requires a lot less time, and, despite what a lot of people claim, for me it's more intuitive than OOP.

    Object orientation was really designed for massive, distributed software projects, where you aren't going to be familiar with every variable, and aren't going to know what should or should not be touched. And the paradigm really does lend itself well to GUI environments, where you can treat windows and such as objects. For that stuff, OOP works. Almost all of today's really big software and GUI apps are written in C++.

    But Perl doesn't power too many really big projects, and it certainly isn't going to be used to write Gnome or KDE apps anytime soon. It's mainly used for parsing text. Does the "Practical Exctraction and Reporting Language" really need to treat all the text it's slicing through as objects? I don't think so. Perl is the quickest and dirtiest language of them all. Only in Perl can I do something like
    #!/usr/bin/perl
    use Time::CTime;
    print(ctime(localtime));

    and have a prayer of it compiling without any warnings or errors. Most every Perl app I have ever written or seen has been to do really simple things - e-mail form data to me, prune my directories, etc. etc. In such cases, OOP is complete overkill. Off the top of my head, I can't think of a Perl app that could really use OOP. In some of the larger CGI apps that I have written, e.g. a shopping cart w/CC verification & inventory control and lots of other goodies, I gave Perl OO a try and didn't like it at all. Maybe I'm a poor OO programmer? Dunno. But I found it to bee too much work for a language whose motto is TMTOWTDI.

    The authors of Ruby want to replace Perl. It's in the faq: "matz hopes that Ruby will be a replacement for Perl ;-)" I'm not sure if this is a good idea. Perl got to where it is today precisely because it is ultrasimple. Why muddle it with lots of OOP complexity, no matter how elegant it may be?



    --
    --

    I think there is a world market for maybe five personal web logs.
  2. Ruby vs. Perl code shoot-out by baldur · · Score: 3

    I'm just starting to try Ruby out, and I haven't used it for anything big or important yet, but it seems to me that its main advantage is being rather more readable and probably more maintainable than Perl (which I still haven't stopped loving anyway...). Here is a small sample, lifted directly from the cgi.rb module:


    def CGI::parse(query)
    params = Hash.new([])
    query.split(/[&;]/n).each do |pairs|
    key, value = pairs.split('=',2).filter{|v| CGI::unescape(v) }
    if params.has_key?(key)
    params[key].push(value)
    else
    params[key] = [value]
    end
    end
    params
    end

    Now, a more or less "literal" translation into Perl would look like this:


    sub CGI::parse {
    my $query = shift;
    my %params;
    foreach $pair (split(/[&;]/, $query)) {
    my ($key,$value) = map { CGI::unescape(\$_) } split(/=/,$pair,2);
    if (defined($params{$key}) {
    push @{$params{$key}}, $value;
    else {
    $params{$key} = [$value];
    }
    }
    %params;
    }

    Despite superficial differences, you are able to tell from this example that the strongest influence on Ruby has been Perl. The examples are essentially the same. Someone with a background in Perl (like myself) has a much easier time learning Ruby than, for instance, Python.

    What I like about Ruby:

    • Less punctuation than Perl and hence more readable. (This applies to braces, parentheses and semicolons, and maybe also the Perl vartype-symbols $, @ and % - though I'm of two minds about those, as I also think they contribute to clarity in most cases).
    • You don't have to use local or my to get local/lexical variables. Variables in Ruby are local (not lexical) by default. (When I'm writing Perl, about 95% of the variables I use are lexical. That's a lot of my's!)
    • The way you can easily string methods after each other using dot notation: variable.method1.method2(/regex).method3
    • The way you can easily act on a reference rather than return a value, using "!", as in str.gsub!(/\"/n, '"'). (Although this particular example would be a bit more compact in Perl: $str=~s/\"/"/g).

    What I don't like about Ruby:

    • The iterator syntax (array.iterate{|v|, do_something(v)}), which admittedly is quite logical but for some reason gets on my nerves.
    • No use strict.
    • No CPAN (though The Ruby Application Archive is a good start).
    • No poetry... at least not yet.

    So, on the whole I think Ruby is quite nice. I'll follow its further development with great interest. But for now, I'm too attached to Perl to make the switch.