[ruby-talk:9985] Re: Ruby refs on Slashdot

On Sat, 27 Jan 2001, David Alan Black wrote:
 
> I have to admit that I haven't kept up with the culture of slashdot,
> so I'm not in a good position to know how worthwhile the exposure is
> in exchange for yet another barrage of not very knowledgeable (as
> regards Ruby) Perl-conformity tests.  It still bugs me.  Someone
> reading this:
> 

It was Distaeli, I believe (could have been Gladstone, I get them mixed up) who
remarked "There are lies, damned lies...and statistics." The truth is, it is
very difficult to write a truly objective benchmarking routine across various
platforms/languages/whatever even to run under ideal 'laboratory' conditions. 
It is nearly impossible (nothing is of course truly 'impossible' -- if it can
be conceived, and bbelieved, it can be achieved) to write the same factored to
the 'real world'. So...as a result I take benchmark comparisons across varying
domains with a considerable grain of salt.(Benchmarks _within_ a given domain
are another matter.)

I think all of us who have explored these things have found that things which
benchmark favorably in 'the lab' don't hack it (a pun?) when put to use in a
'real world' environment. One of the very interesting things about Ruby is that
IMO anyway it seems to port very nicely to 'real world' requirements. It is a
very good 'hacker' language (in the original meaning of the term 'hacker' and
not its recent bastardization and misuse (abuse) by the US media) in that one
can address 'real' (as opposed to abstracted or idealized) problems using it.
The Class/Module/Methods structure means that, if you need to solve something
fro it the native language does not contain a built-in solution (or does, but
it is not obvious at ones current level of understanding of the language) you
can 'invent' a way to do it. I know this is not unique to Ruby, but IMO Ruby
expresses this trait very well.

IN addition, Ruby offers the person coming over from procedural language
conceptuality and easy entre`, something that meets the 'real world'
requirement of getting up and productive quickly in a new domain.

> that the next person who tries Ruby, and the next, and the
> next.... will reinvent (and get snagged on) comparisons like this.

Well, IMO, a truly effective 'benchmark' for languages would go something like
this:

Line up a number of programmers in different languages, present them a
'problem'. Time them, then from point of beginning to end of final execution.
Each segement of the series can be timed, as well, and worked into the overall
score, which, of course, takes into account overall time from start to finish,
how adequately and elegantly the problem is 'solvd', resource utilization and
projected runtime efficiencies over the life cycle of the running program.
Assignment of points re other factors such as maintainability would, of course,
be subjective (unless a test were set up to include this over a period of
time).  

At any rate, such an approach to 'benchmarking' would IMO provide a more
reasonable measure of the true qualifications of one language vs another in
relation to a 'real world' productive environment, which is a lot more complex
(and demanding) than runtime tests alone.

 > Or is it just a matter of the passage of time and an additive effect?

More than likely you are correct here.  People tend to gravitate towards those
things which solve their challenges in the most efficient manner, is easy to
implement and is not too dear in terms of time and money costing.  Though not
alone, Ruby certainly qualifies quite well, I think, in these terms. :-)

Regards,

Kent Starr
[e-mail]