From: W Kent Starr <elderburn@...>
Date: 2002-09-06T00:13:40+09:00
Subject: Re: suggestions to the Ruby community

On Thu, 2002-09-05 at 04:35, Peter Hickman wrote:

> 
> The problem I think is that for a Perl or Python shop then Ruby might be 
> better but not to the extent that moving from C to Perl was.
> 

Agreed. That is sort of what I meant when I noted the move from
perl/Python to Ruby was paradoxically a greater hurdle than from C to
perl; the -apparant- effort/reward ratio is much less.

> It takes a programmer to see the advantages of Ruby whereas a suit could 
> see the results / advantages of Perl over C (faster development, quicker 
> fixes and CPAN).
>

The corporate exec, quite correctly, sees everything as a bottom line
issue. Increases in programmer productivity translate into decreased
costs and/or increased revenue which adds black ink to the ledger. The
exceptionally brilliant exec recognizes that "study" time translates
into increased productivity; the average exec does not.

The quote from Lincoln posted here was very apt. In today's typical
corporate environment, woodchoppers would be expected to sharpen their
axes on their -own- time! :-) The end result, of course, is that a lot
of corporate woodchopping is done with dull axes!!! ;-)
 
> Don't underestimate CPAN, here if we have a problem we click over to 
> CPAN pick up a module and away we go, it doesn't matter that it is just 
> a wrapper around a .so as far as appearances go Perl has provided a 
> solution and it was quick and easy.
> 

CPAN is a wonderful thing. -If- there exists a module to solve a given
problem it is relatively easy to find and, for someone with a basic
understanding of perl, easy to adapt. If one doesn't exist, someone
proficient in perl can create one.

Increasingly, the Ruby community is developing quite an extensive
collection of libraries, as well. Unfortunately, it is not (yet) as easy
to find what you need as it is with CPAN. I expect this will be
addressed and corrected soon and will be one less barrier toward the
adoption of Ruby by a larger number of programmers.

> The reason that I don't use Python that much is because it wasn't /that 
> much better/ than Perl (and Perl has CPAN).
> 

And, for quite a while Python lacked the regex slice and dice
capabilites of perl, which is one of the latter's greatest strengths.

> The reason I still haven't dumped Java is the copious libraries (no 
> matter how badly designed) and especially Swing.
> 
> Perl => CPAN

Add regular expression parsing. In the DOS world, pre-perl, we used
dBase for slicing up ASCII reports. If Excel (which was our raison for
Windows) not come along we would have switched to Unix systems far
earlier, primarily because of perl and regex.

> Java => The API

You might also add here the fact that Java "talks" with Javascript quite
nicely. In a world where increasing focus is being placed upon Internet
distributed computing this is a significant advantage as much of the
computational overhead can be shifted to a zillion clients while the
server does what it does best -- serve.

> Ruby => ?

IMO "?" => "potential". Again IMO Ruby has a -lot- of this. I believe it
is a vastly easier language to teach, thus the potential to leverage
existing human resources is greater. Its "open sourcedness" and built-in
C API lends itself well to serious customizations. (Ninety percent of
software developed is for internal use and not for resale.) It's
expressiveness means easer maintainabilty; like a ship, the bulk of
overall software cost is maintenance, not the building. 

Quite frankly, I view Ruby as a potentially viable alternative to the
Java, PHP, perl mix that currently dominates corporate development in
the area of web services. I believe a team of adept Ruby programmers can
provide more robust solutions within that environment in a shorter
period of time. This is only a theory, of course, yet to be tested. 

> There is more to the acceptance of a language than the syntax.

Agreed. IMO syntax is among the least of the criteria (outside of its
effect upon readability); scaleabilty, maintainabilty, conceptual model,
available libraries, etc. are far more important IMO.

Regards,

Kent Starr