Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Thursday January 09, 2003
11:53 AM

Ruby for Perl programmers

[ #9867 ]

Last night at our Portland Perl Mongers meeting, we had a gentleman named Phil Tomson give a presentation named "Ruby for Perl Programmers". It was very interesting and I would certainly like to see more of the language. I also discovered that Ruby is in widespread use as Intel. Apparently, it's not an "official" language and no one will be hired for their Ruby knowledge, but if you choose to do your work in Ruby, no one's going to scream at you. This seems to be the way that Perl crept in to many shops.

Miscellaneous goodies.

Everything is an object.

3.times { |i| puts i }

Continuations make for easy iterators.

def fibUpTo(max)
  i1,i2 = 1,1
  while i1 <= max
    yield i1
    i1,i1 = i2,i1+i2
  end
end

Decent exception handling, but from what I could tell, failure to trap exceptions is not a compile-time error. I'd love to have something like that in Perl (with the "compile time" part being optional so as not to destroy simple utilities).

We also had one of the largest turnouts for a meeting that we've ever had.

Update: I almost forgot one of the things that I really appreciated. Given an objects, simply call "method()" to get a list of methods. For example, the built-in variable "RUBY_PLATFORM" will tell you the platform you are on. Since everything is an object, here's how to find the methods for this variable:

ruby -e "puts RUBY_PLATFORM.methods"

I noticed that one of the methods was "class", so I called it:

ruby -e "puts RUBY_PLATFORM.class"
String

There's an interactive Ruby interpreter which makes this simpler. I'll have to play with that.

Update 2: From an email one of the attendees sent:

  • Phil Tomson, not Thompson (corrected above)
  • continuations are not the mechanism use for iterators, blocks are.
  • methods() (and many variations) is the way to get a list of methods
  • method(:method_name) is the way to get a usable copy of a method that you can play with tangibly

use.perl.org regrets the errors :)


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Ruby for Perl programmers 11 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I've said it before and I'll say it again: the only thing that stops me dumping perl entirely for ruby is maturity. If ruby had CPAN and all the oodles of modules (and I guess if I was as skilled in ruby as I am in perl) then it'd be byebye perl.

    Sadly [1] though perl's CPAN (which is mostly what keeps me here, but also the maturity of the perl development team - lots of people vs ruby's 1) is lightyears ahead of anything any other language could just come up with overnight now.

    [1] Only sad for the other l

    • Not that I wish to chase you away from Perl, but Brian Ingerson feels your pain and is working with others to create the FreePAN [freepan.org]. It's just started, most of the links are broken, but he does have Ruby content up there. In the process of creating that, he discovered that much of the Ruby Application Archive [ruby-lang.org] (RAA) consists of broken links (much like FreePAN, I suppose :) The RAA is actually just a bunch of somewhat organized links to the download pages for the programs. There's very little consistency and

      • The other pre-cursor to this is that Ruby has no standard installation procedure - almost every module does it differently. So there's no "perl Makefile.PL", there's no "h2xs" to create a standard module layout, there's no "make dist" so that all modules are created the same, etc.

        Until it has that sorted out, a CPAN for ruby is no better than RAA.

        But I believe it will get there eventually.
        • I feel your pain, but I can live with the installation issue. It's *usually* just a matter of reading the module's README, although I realize that the stuff most people come up with (including me) isn't very flexible. A couple folks from CORE (Colorado Ruby Enthusiasts) and myself plan on getting together to rework mkmf so that it works like Perl's MakeMaker. That's my plan, anyway.

          As for a Makefile.PL, the closest equivalent is the extconf.rb file, which does the "make", "make site-install" thing (ass

          • Learn from the past and don't "emulate MakeMaker". Writing out makefiles is dumb on many levels. First of Perl or Ruby is more than capable of doing everything make can do. And Perl (via File::Spec and others) has portability built in. I bet Ruby has some of that too.

            Furthermore, you can only guarantee that a user has Perl or Ruby installed, not make (especially on Win32), so why depend on an external program that offers very little not already available to you in the implementing language?

            See Perl's
  • it's slow. I wrote up a test script in Perl, Python and Ruby to do a regex search of a large text file. I'd post the numbers, but it would be ugly to look at. :) Long story short, Ruby was slowest of the three with execution times three times longer than Perl or Python. By the way, Perl was the fastest, but you knew that already. :)
    --
    Buck

    • Perhaps it depends upon how you wrote the program? From what was presented at the presentation, Ruby tends to be about 3% slower than Perl (whatever that means). If your program is running three times longer, I suspect that it's somehow due to the structure of the program. (unless, of course, there's something really funky about Ruby regexen that I am unaware of).

    • Show us the code and give us an example of the text file. That, or show the profiler results and I'll show you where/how you can optimize it (if possible).

      You're right, though. Perl is slightly faster than Ruby in most cases. This has mostly to do with interpreter startup time, but I think the Perl Development team also has simply had more time to tweak the C code. This is the sort of thing that will improve over time.

      Patches welcome. :)

      • Perl Development team also has simply had more time to tweak the C code

        Yes, that damned Perl Development team. They've done such a bloody good job of tweaking stuff already that I'm finding it very hard to get perl to go any faster. And the parrot folks are even worse - they're trying to get it fast as they design it, so that us retrofit tinkerers can't even squeeze any more out of it. :-(

        • Note that there has been some interest in and work put into the integration of parrot and ruby (named cardinal in the ruby community). That would remove (nearly all) the speed and library differences between perl and ruby.

      • Posted it all here [perl.org] for everybody's perusal. I expected Perl to be faster, but not by 3:1. I really hope it is something wrong on my part; I like Ruby a lot.



        Thanks,

        --
        Buck
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.