From: Kirk Haines <khaines@...>
Date: 2004-01-17T03:40:54+09:00
Subject: Re: Fighting Ruby's bad fame

On Sat, 17 Jan 2004, Lothar Scholz wrote:

> Hmmm, it is not the amount but the quality of documentation. I still
> find a lot of functions very bad explained. No exact mention what
> exceptions are raised, what are the exact input values etc.
> Look at the man pages for unix syscalls or MSDN to see how functions
> must be documented.

I have to agree here.  The overall quality and quantity of documentation 
for many things Ruby is less than what I was used to, coming to Ruby from 
Perl (and C, and Java, and...).  I think that some of this might be due to 
language issues -- human language issues -- and that if I could read 
Japanese I would find more abundant and more complete documentation, in 
some cases.  That certainly isn't a complete answer, though, as there are 
many instances of widely used components that lack any sort of substantial 
documentation.
 
> The problem is not that there are not well known applications. It is
> that there is no enterprise application and not even one larger ruby
> application. I searched sometime to find one but without luck. All of
> the apps could be written in one or two month. So they are no prove that
> Ruby is productive for programming in the large and programming in
> teams. I have no problems finding large applications in PHP, Python,
> Perl, Smalltalk or even in TCL.

All of those languages have been around in widespread usage for a lot 
longer than Ruby.  Give it time.  A few years ago I wrote a very large ETL 
system in Perl for my employer at the time.  There was a reliable, fault 
tolerant framework for collecting and moving arbitrary data/log files from 
external locations, identifying when new data was available and retriving 
it, verifying the integrity of the data, etc.  This was coupled to an ETL 
system that used and XML based language to describe the data sources, the 
transformations to perform on them, and what to do with the resulting 
transformed data.  This XMl langauge was compiled by a Perl parser into 
executable Perl to perform those operations.  The system was decently 
fast, and worked pretty well.  It did some really cool things with Perl.  
It took several months to write it, as the entire system was pretty large.

if I were to do it again, I'd do it in Ruby, and knowing Ruby as I do, I 
would expect that the finished product would be more robust, smaller, 
easier to debug, and though probably a bit slower in execution, not 
overwhelmingly so.
 
> And yes there are real technical problems why i wouldn't use ruby for
> larger applications. The common programming style of for example
> adding functions to base classes like Array are a reason why i would
> not recommend the language for large application programming.

I don't see why this, in itself, is a deal breaker.  If code is changing 
the behavior of a base class without one's knowledge, that isn't good.  
However, presumably, when writing code, one is aware of what the libraries 
that one is using are doing.  Now, in part, one has to rely on the library 
author to have provided good documentation, but at least in theory, one 
should know if a class that is being used goes and much with Array.

This is not quite analagous, but in Perl, one can override most of the 
builtin functions in the language.   I know.  One of the tools in my Perl 
warchest was a neat little module that I wrote which made this very, very 
simple.  I used it to wrap a lot of functions with an Exception hierarchy 
that I created.  Someone who used some of my code without really knowing 
what it was doing could be very surprised by this, but in practice it 
never was a problem.


Kirk Haines