Re: Fighting Ruby's bad fame

gabriele renzi <[e-mail]> wrote in message news:<[e-mail]>...

> 
> How do you fight this?
> 

You don't.  Every person and industry is different and ruby (or
whatever) may indeed not be the best choice.  Working in the computer
graphics industry, I see ruby as a potential godsend for replacing
many of the current languages in use (fx houses and those doing cg
movies have done an evolution of using tcl, perl and now python and
sometimes this has led to all 3 of them being still in use in some
tools or applications, with java being used for some web stuff, and
c/c++ for large applications where speed matters).
I love ruby for its syntax, its clean code, its built-in regex, its
ease of building extensions, etc.
Yet, I still cannot completely and blindly suggest it over the other
tools in that industry as it is missing 4 or 5 things imho.  But it is
damn close, if you ask me.


1) Speed.
This is still a critical factor.  As an alternative to perl or python,
I need to match their speed or be better.  Ruby currently isn't there
yet imho.  I'm not sure if ruby's design of opening classes will
hamper it or not.  Perhaps the solution will lie in allowing for a VM
and the possibility to use the language either "on-the fly" or with a
precompilation phase (most languages and OS architectures seem to be
evolving in that direction, too, which would then mean that only the
language's syntax may be of importance, then).  For simple parsing web
pages or small things, speed is not an issue, but vfx houses tend to
do a lot of things in volume and I know with ruby this would bite me.

2) Localized modification of built-in classes.
While arguably a feature of ruby, the truth is that at a large scale
this leaves the door open to chaos.  VFX is a dynamic industry.  Oa
normal production, you have 10 to 50 technical directors, many of them
writing and updating scripts (and all of them with different amount of
programming knowledge), and usually doing so without a true
coordination.  This is not chaos, but it is a true benefit for the
production and the facility.  Lacking namespaces or so is an issue in
ruby and I know such an issue would not even arise for python, so this
is also a minus for the language.

3) Better english documentation.
There's still the need for good english docs of all the libraries that
are shipped with ruby.  There's also the need for documenting what
constructs make ruby a tad faster or slower.  There's also the need
for a solid "cookbook" a la perl or python, albeit some web docs are a
step in the right direction.

4) Better multiplatform support and libraries.
Ruby is still somewhat inmature in dealing with scripts that would be
run across multiple platforms.  Determining the platform, OS and OS
version at runtime is still a pain in ruby compared to python or perl.
 A library for this is neeed asap.  Same for dealing with terminals. 
If I keep having time, I'll try to adress this.

5) Better 3d math libraries.
Matrix.rb is really of no use.  Yoshiyuki Kosano's math3d library is
much need step in the right direction, thou.

6) Better emacs support.  Tools to do automatic refactoring. 
The use of "end" as a delimiter makes it still hard in emacs to
determine to which block it corresponds, unlike a bracket.  Some easy
macro is needed for that.  In some way, ruby seems to suffer from this
a tad like python, which makes refactoring important to keep functions
within a page long.  Thus, automatic refactoring tools would also be a
godsend (specially if they work with emacs and vi like the python
library refactoring does).

7) Multiple inheritance.
While this is something imo a scripting language can indeed do without
(and I kind of like that), it does present a big headache if you want
to integrate a C/C++ library that does depend on multiple inheritance.