[Shootout-list] Stuff

[Robert Seeger]

> We need to ossify "a wide range of languages": My guess is that all
> of my programs should be implementable in D, SML, C#, OCaml,
> C++, Lisp, Java, Haskell, Lua, Scheme, Perl, Python and Felix.
> Is that wide enough?

That sounds reasonable to me... as long as you don't want your
programs to be the Shootout. The Shootout, from my perspective, is
about demonstrating the speed of a wide variety of languages in
implementing a number of small, focused tasks. Yes, some of the tests
cannot be implemented in some of the languages, but that is the way it
should be. If you're interested in OOP, then you can pay attention to
the results of languages that have implementations for the OOP tests.
If you're not interested in OOP, then you can ignore them.

> For non-trivial tasks, it will be impractical to restrict
> implementations to using identical data structures and algorithms.

Such non-trivial problems don't belong in the Shootout, as far as I'm
concerned. Personally, I'd like to see a test that deals with the
speed and ease of handling various Unicode encodings. As it turns out,
the majority of languages can't handle such a test (without external
libraries) and, as such, it's unlikely such a test will be added to
the Shootout.

I tend to think of test size in two ways.

1) If it would require more than one small grouping of unit tests to
show the code works... the test is likely too complex.

2) If there's part of the test that you'd need an external library to
implement (in reasonable space), then that shouldn't be part of the
test. If everyone can make the call to the external library, then why
bother having it in the test.

Addressing the "real world problems" issue... the definition of that
term is different for everyone. For me, all the math, OOP, and
recursion tests are completely unrelated to "real world problems". My
RWP deal with text and binary data processing, Unicode, and threading,
and my choice of language is based on speed of development and the
speed of the language.

At my previous job, the RWPs I dealt with were network management
based, and my choice of language was limited purely by ease of use and
capability, and had nothing to so with speed (i.e. the Shootout
results were completely irrelevant at that job).

As a random note, I've used Tcl at both jobs (one of the languages not
in the suggested list above). I've even written multi threaded code in
it that works on datasets that are too large for MySQL to handle, and
does so in a reasonable time frame. Would I like it to be faster?
Yes... But I'm not willing to trade off the maintainability of the Tcl
code for the speed that I'd gain. It gets the job done, and doesn't
blow up and core dump on the same datasets that MySQL does. As such,
it's good enough.

To summarize, don't assume your definition of real world problems
matches everyone else's. While it may match that of quite a few, it
will not match quite a few more. Having a wide variety of smaller
tests, implemented in as wide a variety of languages as possible, is
"A Good Thing", in my opinion.

Rob Seeger