[ruby-talk:24713] Re: Why is ruby slow (compared to perl)

Robert Feldt wrote:

> Could you elaborate what you mean with "functional programming" in this
> context. FP as in Haskell, Ocaml et al or some FP programming style in
> imperative prog languages?

FP as in self-documenting code.  I've wondered why they decided on that 
nomenclature, because when I first heard it, I was thinking "functional vs. 
OO".  I haven't used a non-OO language in so long, though, I tend to throw 
it around without regard to the confusion it causes.  Sorry.

>> be ignored.  I've often heard that source documentation is optional; that
>> the best way to write good code is to write very small methods and remove
....
> Just so that I'm following: You're assuming that the only/most important
> quality criteria of code is its speed of execution, right?

No, I'm assuming that in some cases, the most important criteria of code is 
the speed of execution.  Furthermore, I'm rebelling against the trend I see 
to completely ignore issues such as speed.  I'm hyper-sensitive, I suppose, 
because I've been coding exclusively in Java for the past 7 years, and I've 
seen what a difference speed can make in the general acceptance of any 
software.  The most beautiful, functional code is absolutely worthless if 
it isn't used because it is too slow.  On the other hand, fast code will 
tend to be used even if it is really, really.  In the end, the users (whom 
we're writing the software for) don't care what the code looks like; they 
just want it to work right and run fast.

Before you jump on me about the hidden benefits of "pure" XP code, a couple 
of caveats:  (1) I'm an XP convert -- we're better off with it than without 
it, and (2) I'm not ignoring the benefits of clean code.  I know as well as 
you that clean code tends to be less buggy and is certainly more 
maintainable.  However, code speed is almost never stressed by XP 
advocates, who tend to stress "never break the rules".

> Just so that I'm following: You're assuming that the only/most important
> quality criteria of code is its speed of execution, right?
>
> Do you often find this to be the case in your projects?

Yes, and no.  Especially because we're using Java for two tiers of a very 
large three-tier application.  Until recently, as CPU speeds came up to the 
1GHz range, we had a hard time getting people to accept the software 
because it was slow.  Not really, really slow, but slow enough that, over 
time, it became increasingly annoying to work with.  Much of the speed 
issues resulted from things outside of our control, such as Swing's 
performance, but some of the things were due to the fact that we had a 
good, clean design that, unfortunately, had a lot of unwanted side effects. 
Things such as too large an object cache caused the system to consume a lot 
of memory, which slowed things down.  Many small methods caused too many 
calls back to the server with too much overhead.  Eventually, we combined a 
number of objects and methods and sped things up considerably.  I wouldn't 
call the current design elegant, but it is fast enough to be usable, which 
we couldn't say about previous versions.

> IMHO, you should also view the XP stuff in its entirety with unit tests
> showing examples of how to use the code etc.

Yeah, I'm not ignoring that.  XP brings with it a lot of great stuff.

> If you're trying to attain maximum performance then why use Ruby? Sure,
> advance in VM's might take Ruby down to 2 times C (although I doubt

Of course I want my software to be as fast as possible, given the 
environment I've chosen to work in.  There are no absolutes; in any 
environment, there's fast enough, and not fast enough.  Often, the line 
between the two is very narrow.  Even in C, there are cases when you want 
to optimize for speed.  This is why we choose quick sort over bubble sort.  
Quick sort is a more complicated algorithm, but the advantages of its speed 
outweigh the advantages of having "pretty code."  Wouldn't you agree?

> I'd think that if you have a good design, profile, attack the
> bottlenecks and maybe even lift some of it to C then you'll be better off
> than with a poorer design.

True.  I agree with you completely.  XP, however, insists that you 
refactor, refactor, refactor, and remove all possible redundancies.  
Sometimes the way to improve speed and remove bottlenecks is to inline some 
code.

--- SER