All the Perl that's Practical to Extract and Report

Ruby for Perl programmers

Ovid on 2003-01-09T16:53:38

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 :)

Ruby

Matts on 2003-01-10T07:56:30

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 languages!

CPAN for Ruby

Ovid on 2003-01-10T15:43:39

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. 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 (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, in fact, Ingy was mentioning that some of the programs in the RAA consisted of nothing more than Ruby code slapped between a couple of <pre> tags so you could cut 'n paste.

The FreePAN is intended to eventually be a clean, well-organized central repository for free, open-source code. Even a Java category will likely appear, if the project continues. But right now, I don't even think you can call the site "alpha". I'd keep an eye on it and, who knows, you may just find your Ruby CPAN.

Re:CPAN for Ruby

Matts on 2003-01-13T07:58:38

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.

Re:CPAN for Ruby

djberg96 on 2003-01-13T21:40:52

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 (assuming you've included mkmf), although it doesn't do "make test" at the moment; one of our first priorities is to autogenerate test targets if tests are included. Also, mkmf is only designed for extensions. At least, I've never tried it except for extensions, so this will probably be an even bigger project than I think it will be.

Re:CPAN for Ruby

autarch on 2003-01-15T05:41:53

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 Module::Build for a _much_ saner way of handling module installation.

Ruby is great, but...

Buck on 2003-01-11T08:58:09

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. :)

Re:Ruby is great, but...

Ovid on 2003-01-11T20:38:32

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).

Re:Ruby is great, but...

djberg96 on 2003-01-11T21:55:33

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. :)

Re:Ruby is great, but...

nicholas on 2003-01-13T10:57:39

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. :-(

Re:Ruby is great, but...

stillflame on 2003-01-16T17:43:14

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.

Re:Ruby is great, but...

Buck on 2003-01-15T04:05:43

Posted it all here 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,