Hi Bill,
I appreciate the more constructive tone. By the way, I was unfamiliar
with the term "troll" in this context, so looked it up on Wikipedia.
Let me assure you that I am not seeking ways to be inflammatory, and
certainly have not disguised my identity.
You say you jumped into the middle of the threat, so may not be aware
that I did not make the sweeping statement that Ruby is too slow for
real world applications. I agree that its speed is adequate for many
applications. How to categorize application areas is difficult, and
almost any such attempt would be subject to criticism. Your example
about 3D graphics is, indeed, a good illustration of one that would not
be suitable for Ruby.
I like dynamic scripting languages for productivity and do not expect
them to accomplish tasks that require the performance of C. My main
interest is in developing what are sometimes called business
productivity applications, applications that could be developed, say,
with Visual Basic 6. For example, I have written an advanced text
editor with the WxRuby library. I loved the rapid application
development that Ruby helped to facilitate. There are sometimes
noticeable delays, however, in the processing of events by the user
interface, e.g., keyboard events. My experience with other scripting
languages suggests that such delays are not inevitable with a
contemporary scripting languageand modern machinery, so I hope that
Ruby's speed can be improved enough to eliminate these problems. I
realize that a speedier algorithm might exist, but the search for it and
redesign if found also involve development time taken away from other
efforts to advance the application.
Ruby Speed improvements, combined with the ability to create truly
stand-alone Windows executables, are, in fact, important enough to me
that I would pay for commercial Ruby tools that delivered these
features. Knowing of such market demand by me and others, there may be
Ruby entrepreneurs who respond accordingly. On the other hand, if those
of us who need better performance are discounted for raising such
concerns, an impression may be left that the current language projects
and timelines are adequate. This is not to put blame on the core
language developers, but to better convey the extent of interest in such
enhancements to the Ruby development environment.
Regards,
Jamal
···
-----Original Message-----
From: Bill Kelly [mailto:billk@cts.com]
Sent: Friday, July 14, 2006 3:43 PM
To: ruby-talk ML
Subject: Re: How to speed up ruby and make it as fast as possible
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