in reply to Perl to Ruby translator?

Warning: Ramble ahead!

I do love my craft and I agree that Ruby has some things going for it that Perl 5 does not. However, Perl 5 is, for all intents and purposes, a much more practical language. The primary reason for that is the CPAN. In fact, it may be that the CPAN is the last main reason to stick with Perl 5. That's why we needed Perl 6. Perl 5 is old and it shows (though I must confess that I love the language and all of it's quirks :).

If we love our craft, we will grow and discover new things. If you appreciate the conciseness that can be found with rich expressivesness, you'll appreciate the direction that Perl 6 is going. Heck, even Java is beginning to realize that things need to be different. Java 1.5 has enough interesting things in the language (such as Generics and Autoboxing*) that it might start moving in some very interesting directions. Most notably, one direction appears to be less code, which is one of the biggest complaints against the language.

In short, all languages evolve. Perl is evolving, but the direction is exciting. The new features make the language simpler without the overhead that C++ (to use your example) forces upon us. For example, to iterate over lists in parallel:

for @ids, @customers -> $id, $customer { ... }

That's the sort of thing that people need to do all the time, but write buggy code to accomplish. If your complaint is that Perl 6 will be a huge language, you're right. I'm not sure how that's a complaint, though. It's still easy to learn the basics and adding little bits and pieces of the language as you go is not a Bad Thing. However, these new constructs make programs shorter and clearer. Not like C++ at all :) To really get a feel for it, though, check out Perl 6 Essentials. It's a very easy read and while it's admittedly already out of date, they will be updating it every year until Perl 6 comes out.

Cheers,
Ovid

New address of my CGI Course.

* Autoboxing is nice, but I find it pretty annoying that it's a way to deal with a broken "feature" of Java rather than just fix the darned feature. Why won't Sun listen to their users? Or are their users so used to mixing primitives and objects that they don't realize there's a better way?

Replies are listed 'Best First'.
Re: Re: Perl to Ruby translator?
by Anonymous Monk on Oct 11, 2003 at 03:35 UTC
    I've used, taught, and advocated Perl for several years, and will continue to do so. I toyed with Ruby two years ago, came back to it a year ago, and now choose to implement most of my personal projects in Ruby. It is concise, expressive, and flexible, and while its RAA isn't as developed as CPAN, it does have nearly 1,000 application/library packages many of which are quite mature (and libs for ftp,http,stmp,pop,telnet,webrick,yaml,xml, among others are included as part of Ruby's standard library). It also has flexible iterators, and you can iterate over multiple Enumerable objects already :-)

      What the AM said ;-)

      I've been learning Ruby on the side this year and it has been a most enjoyable process. Nice language. Well designed. Far fewer odd corners than Perl 5.

      I'm seriously considering using it for some commercial work if the opportunity arises.

      Only two downsides that I've encountered:

      1. The lack of CPAN. RAA is nice but not quite at the same level of utility yet. However, for many applications all you need is there.
      2. Speed. Its surprisingly slow. Again, not always a problem. Also, there is no real reason it won't get faster in time. It is, after all, just a trivial matter of programming :-)
        Now, just imagine Parrot has matured and we have both Ruby-over-Parrot and Ponie. Guess what..? ;)

        Makeshifts last the longest.

        I found the speed difference between ruby-1.6.7 and perl-5.6.1 to be about 50% in favor of perl. But perl-5.8.0 is about 50% slower (perlio defined this time), and ruby-1.8.0 is about that much faster, so the difference now is only a few percent.