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

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.