From: "W. Kent Starr" Date: 2001-01-28T05:01:32+09:00 Subject: [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 elderburn@mindspring.com