From: Ryan Leavengood <leavengood@...>
Date: 2005-09-30T23:23:28+09:00
Subject: Re: In your opinion....

On 9/30/05, Greg Loriman <do@not.reply> wrote:
>
> Coming back to your question : Ruby is nice, but don't get bamboozled by the
> ruby crowd. Someone with a clear head needs to come along and critique the
> language more objectively than I have seen so far. hOwever I'm not saying
> its a bad langauge; far from it,

I really enjoy programming in Ruby, in fact I would say it was my
favorite language. But it is not perfect, and I'll try to describe
some of the flaws I see in it. To give some background I've been
involved with the Ruby community since 2001, so I think I have a good
perspective:

- It is slow. Or to be more exact, compared to some other languages,
Ruby is slow in certain problem domains. Recursion is quite slow for
example. Part of the problem is the fact that the current Ruby
interpreter works by parsing the code into an abstract syntax tree and
then executing that tree directly. The normal standard for
interpreters these days is to compile the code into an intermediate
byte-code and then executing that, which is usually much faster than
the current Ruby method. Fortunately we have a very smart fellow named
SASADA Koichi working on a Ruby byte-code interpreter called YARV (see
http://www.atdot.net/yarv/), so this flaw won't be around for much
longer. Of course the reality is that Ruby, by its very nature, can
never be as fast as a static compiled language like C or C++. Plus as
others have said there are certain problem domains where you would
have to use those kind of languages instead of Ruby (operating system
kernels, device drivers, etc.)

- Ruby is almost too flexible. This is subjective, but the powerful
ability to modify base classes of the system brings a certain
responsibility that some people may not consider. This doesn't apply
too much to little throwaway scripts that we all tend to write, but
there are several examples of Ruby libraries doing stuff here that has
bitten people. These are probably some of the hardest bugs to find,
since few people think that the core classes could have been changed
under their noses. Fortunately most Ruby library developers are aware
of this and they follow certain etiquette rules to ensure these kind
of problems don't come up.

- For large projects the flexibility of Ruby source code organization
could cause problems (in that you aren't forced to put one class per
file for example, like Java), but again this isn't that big of a flaw
because it just requires a small amount of discipline in being
organized with your code.

- The state of Ruby libraries still leaves a bit to be desired. This
has been a persistent problem even since I started with Ruby in 2001,
in fact it inspired me to create the original RubyGems prototype which
has since been supplanted by the RubyGems system we have today. While
this has certainly been a big improvement, not everyone makes use of
the gem system, so there is still some fragmentation. Also RubyGems
still has a bit of a "tacked on" feeling, and this won't go away until
its flaws are fixed and it is fully integrated into a Ruby release. In
addition there are tons of "dead libraries" that haven't been touched
for months or years, yet still provide useful functionality. There are
some efforts to dust off these libraries and bring them up-to-date
though, so hopefully we will see some improvement here.

- Ruby documentation also leaves a bit to be desired. Thanks to the
great Pickaxe book and several others, the Ruby core classes are
pretty well documented, but there are still certainly areas for
improvement there. But I find that way too many libraries (especially
many that actually ship with Ruby) have little or no documentation. I
can't tell you how many times I've just decided to read the source
code of some library to figure out how to use it because no decent
documentation was available. Again there are efforts to solve this
problem as well, but I think the solution needs to be more of a change
in Ruby culture to promote documenting libraries one develops, instead
of leaving that job to someone else. A big part of this could be the
language barrier, since many cool Ruby libraries are developed by
people who may not be confident in their English ability. In that case
some good example code would certainly be better than nothing.

- There is no standard Ruby GUI. Maybe this is a moot point with how
things are going with the Web these days (and Ruby has that realm
covered with Nitro, Rails, Wee, etc), but desktop operating systems
and applications aren't going to disappear overnight, so a good and
somewhat standard Ruby GUI would be nice. Right now there are
certainly many options when one has to create a Ruby GUI (too many in
fact), but each has particular flaws or is lacking maturity in
comparison to the same GUI bindings in Python or another language.
This is a very difficult problem though, and even Java has had a lot
of struggles here (despite tons of money and time from Sun and many
other companies.)

This email is already too long, so I'm not going to answer the
original question of this thread, but hopefully the above will be
enlightening.

Ryan