[Shootout-list] Stuff (external libraries)

[Bengt Kleberg]

skaller wrote:
...deleted
> The most obvious example concerns 'external' libraries,
> where both terms 'external' and 'library' cannot
> be well defined.

what we can try to do is to have rules for how to use 'external' 
'library' in the shootout. it would not be a real word definition. just 
a shootout defintion. which, if documented, should be ok for 
sufficiently many people.

...deleted
> Another example is a language like Felix, which 
> is designed to embed and be embedded in C/C++:
> in one sense all Felix code is C++, and all C++
> code is Felix.. the languages have utterly
> distinct syntax, but they bind together at 
> the source code level. Can an embedded C function
> provided for performance be deemed improper when
> the central design principle of the language was
> precisely to allow this?

since it is in the source, and not in a library, this should not be a 
problem.


...deleted
> I believe the answer is: the purpose of the Shootout
> should NOT be to measure performance. That is indeed
> inherently stupid, whether large or small scale.

i might be stupid, but i like to measure performance. i like it so much 
that i want the shootout to include more measurements than the current 1 
(well, 3 very close).


> My view is the shootout should *showcase* languages.
> The tests should be designed to exhibit strengths
> and weaknesses, perhaps to allow people to choose
> the best tools for the job, perhaps to allow people
> to learn new techniques and new languages.

even in its current incarnation the shootout do showcase languages. you 
get to see lines of code, speed and memory usage. since only 1 value is 
allowed you do not get to see limitations, but that can be fixed.


> In my view, the program times should not be
> the results of the test, but part of the specification:
> the idea should be to write the cleanest possible
> code to solve the problem with reasonable performance.
> The result of the test is the *code*, not the time.

i really think that one result of the test is the code. and also speed, 
memory, etc. to narrow the current (too narrow) focus even more is not a 
good idea. imho.


> With this kind of purpose, many of the arguments
> about what is allowed and what is not are moot.
> If an external library is used, that should be
> considered perfectly acceptable, the main point
> would be to be sure that the need is documented.
> Hopefully, the extra messiness on the comandline
> needed to link the library will create a suitable
> negative impression for a C solution, for example,
> compared to a Python one (where an import statement
> in the program is all that is needed).

since the command line is less prominetly displayed than the source i 
think this is not likely to happen. moreover, it owuld open up for all 
langugaes with a ffi to have c code for everything. everything would be 
faster, but less fun.


bengt