In the olden days, programs used to be a combination of assembly and a 
low level compiled language like C or Pascal.  Lotus was actually 
written wholly in assembler back in the day.  The comparison of C to 
assembler was, in the early days, much like the comparison of Java to 
Ruby today.  However, the speed comparison of assembler to C did not 
sustain its original conclusion for long.  As compilers improved, it was 
possible to wrote wholly in C and have it execute faster than in pure 
assembler.

Personal anecdote #1: actual testing

I was working at Quantum at the time (hard disk maker) and this very 
controversy arose.  The managers listened to the philosophical debate 
for a while and decided to settle it.  We had volunteers from each side 
to write code in their idiom doing theoretical and practical tests of 
speed.  By theoretical I mean do <this thing> X times and see how fast 
it is.  By practical, I mean that you had to see how many seeks, 
read/writes, etc you could get in a certain time with the different 
algorithms.

The pure language, no assembler, won hands down.

Personal anecdote #2: compiler comparisons

I was a sysop on compuserve for the Borland topics for a while and this 
came up again in various threads.  There were several assembler devotees 
that were pushing their notions.  They maintained that they could write 
an assembler routine that was fewer lines than anything that a compiled 
language could manage.  They tried several examples.  In each case, 
someone wrote a pascal method, compiled it, then looked at the generated 
assembler and posted it.  The compiled version was always shorter than 
the one written in assembler.

Does this prove that it will always be so?  Nah.  It proves that trying 
to out compile the compiler these days is waste.  You MAY get one line 
less here or there but only with tremendous effort, so why bother?  Is 
assembler useless?  Nah, but its reputation is overrated.

What does this mean in this context?

The speed of execution is not as simple as looking at the stopwatch. 
With hardware prices coming down down down, you can get muscle machines 
to pick up any such slack.  But, that costs money.  Well, so does 
development.  If you can develop a lot faster in Ruby, is it worth it to 
get another machine and run some of the parts in threads that will get 
it done in faster fashion?  If it is not, then speed may not be as 
critical as you think.

There are many ways to get things moving faster.  Here is one I saw 
recently that I consider to be quite helpful.  (It also has one of my 
favorite lines I have ever read in a technical article:

"However, all these caching measures won't hide a basic problem: you are 
performing lots of database queries, and it's harshing your mellow."

How can you top that???

In short, Java might run faster, but that should not make a difference. 
You can use hardware and design to make up for that.  After that is 
done, it is the time to develop and maintain the code that will be what 
matters most.

FWIW, and IMHO
-- 
Posted via http://www.ruby-forum.com/.