[ruby-talk:11167] RE: Ruby success stories?

Hello Phil,

> Anybody out there got anything I can use as a reference?  It 
> would be nice 
> to have:
> 1) What the application does.
> 2) Who was it for or where was it deployed?(if you can't name the 
> company, that's OK, just tell me what industry they're in)
> 3) How long it took how many engineers to develop.
> 4) How big is it? (lines of code)
> 5) Whatever other comments you can provide ("It saved our company a 
> million bucks!")
> 
> 
> Also, I'm supposed to compare Ruby to Perl, Python and Java (I really 
> don't think Java is appropriate for this problems space due 
> to lack of built-in regex and ways of running external apps, 
> but I'll give it a shot).

We use gnu regexps with Java. 

  http://www.cacas.org/java/gnu/regexp/

So depending of the application it's a viable contender too.

> The centerpiece of my argument is dRuby - it allows 
> us to deploy a distributed app like the one we need to
> develop very easily in Ruby.  I know that Perl doesn't
> have anything quite like it, but what about Python?

This is going to be a bit long story that random readers might like to skip.
OTOH, maybe those readers would not have get this far, so the disclaimer
might be here without need ;).

One thing I could mention right away is a bunch of scripts which make Ruby
Mine. Although it's not a commercial package (nor won't be published any
time soon) there's a special feature that I'd like to highlight.

I thought to show RAA information but I had to get it first. For that I
wrote a script which "surfs in" at ruby-lang.org's RAA pages and parses out
the meaningful information. Wasn't too hard. But there's a catch. Every
package's details are on their own page. And assuming exponential growth
rate for the highly successful and fit population on it's early phases of
life time (let me loan some biological terms :) I thought I'd run out of
downloading time at some point (one snapshot of information will take more
than hour). I tested it, and I run out of time at once, since there were
more than 200 packages and on average a page took more than 18 secs to
download.

So I had to distribute the loading somehow. Luckily I found out that CPU was
barely used, so it was all about bandwidth I got HTML back, and I knew it
wasn't about the bandwidth of the line on my end. I could use more bandwidth
by spreading the loads over multiple processes (and even hosts) or by simply
making the loading concurrent. I chose the latter.

First I thought I have to work with the select loop on my own, and maybe
partially rewrite the HTTP routines. Or maybe I'd do it in a (older) Perl
way and spawn multiple processes and let them talk back to the mother
process. I chose the latter and changed my course again.

After five minutes of work I suddenly realized that Ruby already had
everything I needed. It handled the select loop on it's own and it had
threads to utilize it well. So I changed my course and went on writing a
simple concurrent loader.

In the end sharing the work between worker threads so that CPU was fully
utilized took about 50 simultaneous loads. Coding it with proper timeouting
took about 30 minutes.

Oh, why I'm telling all this. This might be a simple example of simple task
but highlights why I like to work with Ruby. 

I had to make my own select loop (or event handling engine) in Perl couple
of years ago when it's event handling packages were under development and a
library called libwww-ng (Stein's next generation package for http handling
etc) were just forming. If I had Ruby those times I'd estimate my app would
have took under one month instead of two. Equivalent code might be trivial
to code in Perl these days as the situation with commonly available CPAN
packages might be better (haven't worked with Perl lately :) but that is not
my point. My point we can almost discard the fact it took development time
to have the functionality around, but we can't discard the fact there's
about no one in my organization who's familiar with the code or the design
and would be willing to take over the maintenance of it. The very reason
being that code is very specialized in-house software since it has not been
published.

To summarize,

  1) the task at hand was trivial to implement in Ruby
     (the shared between nodes would have been too with DRuby)

  2) about equivalent code in Perl took some amount of
     infra-level coding

  3) I'm quite positive the code produced is more easily
     accepted for maintenance by other coders

The third point is still untested and lacks evidence, but I'm basing it on
my own experience when I was a Perl coder and I'd have accepted most code
easier if it had been written in Python than in Perl :). OTOH, the couple of
snippets I've shown in Ruby have been tremendously easier to explain.
Or..hmm.. change it "to discuss about". :)

For those who might find this text inflammatory I can assure I still respect
Perl a lot, and would use it as an implementation language for many
applications. I'm also aware there's nowadays many more useful packages at
CPAN which might make the task I described a very easy and simple job. And
sometimes the reason to use Perl instead of Ruby is really because there's
already some nifty package at CPAN already.

	- Aleksi