[ruby-talk:11256] Re: C scripting using Ruby (instead of Perl)?

[e-mail] (Phil Tomson) wrote:
>
>In article <[e-mail]>,
>Ben Tilly <[e-mail]> wrote:
> >ts <[e-mail]> wrote:
[...]
>I'm doing a Language comparison matrix for an upcoming presentation and
>intitially I was going to give Ruby a '4' (highest rating) and Perl a '2'
>(1 is the lowest rating), but in light of Perl's Inline module, I'd have
>to give Perl a 4 and Ruby a 3 - Inline actually seems to make extending
>Perl with C a bit easier than extending Ruby with C.  Now, I haven't used
>Inline in Perl (I read the article in The Perl Journal) and I have
>extended Ruby with C - so it' possible that Inline isn't that easy when
>you get down to actually using it.

It really is as easy as it looks.  At least for small
things.  (I admit to not having extensively abused it
yet.)  The only gotcha that comes to mind is that your
C types need to have a typemap to Perl.  And those may
take some knowledge to make.  (You start with typemaps
to most things that you really need though.)

Ruby would, of course, also need to have appropriate
typemaps.  But those may well be easier to write from
scratch for Ruby than they are for Perl.

Of course the *right* solution is to see if Swig can be
convinced to automatically spit out the necessary
mapping... :-)

>      Of course, we're talking mechanics
>here - the other issue would be Perl's C API vs Ruby's C API.  I find
>Ruby's to be very straightforward and easy to use, but I have to admit I
>haven't done much with Perl in this department.
>
I have not played extensively with this, but my bet would
be that pre-Inline this was a hands-down win for Ruby.

But with Inline, well take a look at
http://www.perl.com/pub/2001/02/inline.html and
scroll down to the section on "CPR".  No joke, that
turns Perl into a C interpreter where you can inline
and run Perl code at will.  Startup is, obviously,
much slower than an equivalent C program.  It is not,
however, too much worse than a Perl program...
> >
> >Now is it worth the extra work of getting Inline set
> >up just to make it easier to get C working with Ruby?
> >Almost certainly not.  But is it worth that work for
> >the potential of then being able to link in other
> >languages?  (Which is where Inline.pm is going in
> >Perl.)
>
>I actually think that at the moment, it would be more valuable to have an
>Inline for Ruby that allows you to inline Perl code.

The fastest way to that goal is probably to write a
Ruby binding for Inline.pm and then turn that around
(as has been done for both C and Python) to make it
look like you are writing in Ruby with an embedded
Perl interpreter available.  The reality, of course,
would be just the opposite, but sometimes appearances
matter...

As you hint, this solves the problem where Ruby is
unacceptable only because there is something that CPAN
has a module for that you don't want to reinvent in
Ruby.  Well you can easily wrap the Perl interface into
a Ruby interface, and then write in Ruby.  If you later
rewrite that piece you can then just replace the one
section and switch to using real Ruby rather than that
fake wrapper that gave you access to Perl stuff...

Of course if the functionality of Inline is of interest,
the best long-term solution is to have a straight Ruby
version.  Trust me, Ruby does not want to be passing
stuff too and from Perl when wrapping code from C, C++,
Python etc.  I think that very often a native Ruby
interface will be significantly more straightforward and
efficient than Perl's interface to either language...

Cheers,
Ben
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com