There are certain sore spots in language discussions which tend to get
feathers ruffled. Seeing this thread has garnered so many replies in
such short time uncovers a sore spot in Ruby language discussion. Ruby
tends to be slower than other similar interpreted scripting languages.
Although some folks won't admit it as a broad generalization this
assertion tends to be stereotypically correct.

Every language has its sore spot. For Python try bringing up
significant whitepace or passing the understood 'self' around each and
every method. For Java try bringing up the truth of 'write once run
everyone' or mixing primitives in with objects for a supposedly OO
language. For Perl try bringing up cryptic lack of readibility and
"bolted on" version updates. For PHP try bringing up secure coding
practices. And so on...

Bill Kelly wrote:
> From: "Jamal Mazrui" <Jamal.Mazrui / fcc.gov>
> >
> > You are mistaken.  Current, stable Perl and Python releases typically
> > execute programs much faster than Ruby.  I suspected such rationalizing
> > and hostile replies in my initial post.
>
> I'm jumping into the middle of the thread, but, I do believe
> you're missing a few important points.
>
> 1. Most of us are already aware of ruby's speed.
>
>    1a. Many of us are able to write entire applications
>        in ruby today, and find that it's "fast enough"
>        for these applications.
>
>          - For example: I have written several internet
>            and web applications in ruby, and for my
>            needs, ruby was plenty fast for these
>            applications.
>
>    1b. Some of us are writing applications for which
>        ruby is NOT fast enough, by a couple orders of
>        magnitude.
>
>          - For example: A 3D video game, with polygon
>            rendering, collision detection, physics,
>            monster AI, etc.
>            I am developing a 3D application, and I'm
>            writing as much code as I can in ruby.
>            But it doesn't matter if someone comes along
>            and says "ruby needs to be faster".
>            Ruby will NEVER, in any foreseeable future that
>            matters to the software I'm writing, be fast
>            enough to handle real-time rendering, physics,
>            and collision detection for a complex 3D
>            world.
>            This is an important point I think you're not
>            realizing: It's not a matter that people don't
>            "want" ruby to be faster.  There is just NO
>            KNOWN technical way to make ruby fast enough
>            for some applications.
>            Therefore, for my 3D application, I write as much
>            as I can in ruby, and code the rest in C.
>            Saying "ruby needs to be faster because I don't
>            want to learn C" is just nonsense for some
>            kinds of applications.  For these applications,
>            recommending C is not "rationalizing away ruby's
>            slowness" and it's not intended as a "hostile
>            response."  It's just true, because there's
>            NO KNOWN way to make ruby fast enough, no matter
>            how much you want it to be.
>
> 2. Probably anyone here will agree with the idea that
>    it would be *nice* for ruby to be faster, provided
>    we don't have to change the language to get the speed.
>
> Did I leave anything out?
>
> As I mentioned, ruby is _already_ fast enough for some
> applications, and _will never be_ fast enough for others.
> 
> 
> Regards,
> 
> Bill