[Shootout-list] Re: Coding For Speed
Shae Matijs Erisson
shae at ScannedInAvian.com
Sun Apr 23 22:54:53 UTC 2006
I think the essence of this email is something I've been wondering about
myself...
> When engaging in the exercise of "benchmarking" inherent in that
> exercise (to me) is to identify coding techniques and paradigms
> within the idiom of the language being used to perform the
> stated tasks as fast as possible.
Similarly, my priorities are understandability and programmer time.
For a given task, I want to be able to turn out a working solution that can
easily be understood by readers in as little time as possible.
To me, source code is primarily communication with other programmers, most
often myself some years after I wrote the original code.
But there's a much greater value in code as communication.
It's hard for me to find library code that fits my clients' needs, partially
because I don't know their needs ahead of time (usually, neither do they).
When I find code that does part of what I need, if it's well-written, if it
communicates well, then I get the greatest value because I can quickly change
or extend that code to do the rest of the task.
> Thus, I disagree that benchmarks are about applying some
> arbitrary programming paradigm to a set of languages, just so
> the "look" of the programs are similar. Benchmarks should
> illustrate how a given language can be used to perform a
> given task (the benchmark) in that language, particularly
> using the best programming techniques and idioms unique to
> that language.
>
> Thus, to me, the primary essence of benchmarking is comparing
> how different languages can be uniquely applied to optimally
> perform the same tasks, and comparing those results.
>
> If there are other characteristics you are really trying to
> compare between languages, it would be best to explicitly state
> them (such as shortest program, etc) and not confuse issues
The problem I see is that it's easy to directly test LOC, CPU time, RAM usage,
but it's really hard to test readability and good use of idioms.
At some point it's like unit testing poetry.
There are some slighly deeper tests, you could also use code metrics like
cyclomatic complexity. ( For more on this, Serguey Zefirov suggested
http://www.cs.stir.ac.uk/~kjt/techreps/pdf/TR141.pdf )
But, I would most value a shootout that has a 'code as literature' section.
I don't know how that would work, and I've never heard of a multi-language
website that does that critiques benchmarks for elegance,
but I do know I would want to read from and contribute to such a website.
--
Programming is the Magic Executable Fridge Poetry, | www.ScannedInAvian.com
It is machines made of thought, fueled by ideas. | -- Shae Matijs Erisson
More information about the Shootout-list
mailing list