ptkwt / shell1.aracnet.com (Phil Tomson) wrote: > >In article <LAW2-F60TrBoe2U8QVj000015b2 / hotmail.com>, >Ben Tilly <ben_tilly / hotmail.com> wrote: > >ts <decoux / moulon.inra.fr> 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