On Friday, 18 April 2003 at  9:19:25 +0900, Michael Campbell wrote:
> 
> --- Jim Freeze <jim / freeze.org> wrote:
> > On Friday, 18 April 2003 at  3:19:08 +0900, Michael Campbell wrote:
> > > > > >> In my experience, the fastest way to access files (by far)
> > is
> > > > mmap.
> > > 
> > > 
> > > Jim, I may be mis-remembering, but wasn't your original
> > > task/goal/test to compare perl, ruby, (and others) at IO?  If so,
> > > isn't using Ruby+C extensions....cheating, somehow?  
> > 
> > Why would this be cheating?
> 
> As I said, I may not understand what you are trying to do.  But if
> you're comparing perl to ruby, compare perl to ruby, not perl to ruby
> + C.  If you "win" with ruby + C, could you not do the exact same
> enhancement with perl, and end up where you started?
> 
> As a contrived example, if it's a simple "copy" test, and 'cp' is
> rippingly fast, then why not just use system('cp foo bar')?  I mean,
> that's ruby, right?
 
We use Perl in a business environment. My quest is not an academic
contest between Perl and Ruby. Perl is the incumbent language
used to write filters for processing large files. The code is
very 'hackish' and not easy to read or maintain. I would like
to replace it with a much more readable language, ie, Ruby.
But, if Ruby is not fast enough, then it will never be 
considered. If it is close in speed, then it could be considered
because of it's readability, but it will still leave an aftertaste
with some because it is not a clear winner.

However, if Ruby is faster and more readable and easier to maintain,
then it is a true win. Forward progress with Perl will have to be
justified, with much effort.

If we write a library in Ruby or extend it with C, it doesn't 
matter. Both are easy to write (unlike Perl). The user of the 
library stays in a Ruby environment.

So, my comparison is with between what I can do with each language
with similar effort. If one language let's me optimize and publish
common libraries with ease, then that's just an added advantage
that that language possesses. If we could do the same with Perl,
we would. We are not artificially constraining it in any of these
tests. (We have several perl experts at our company that have
used the language for years and like it very much. Yet, none of them
know how to extend the language with C for performance. Either
it was not needed, or it is not something a Perl programmer
typically does.)


-- 
Jim Freeze
----------
A professor is one who talks in someone else's sleep.