Terrence Brannon wrote: > Yes, the point of the Shootout is not to see how well a language can > solve a problem. But how well the language can do certain things when > all languages are forced through the same hoops > > So here they are testing the ability of the language to execute > recursive calls. Not the ability of skilled authors to come up with > the optimal solution vis-a-vis space/time.
As I have complained before in the forum, algorithms are not language-neutral, despite what the site proclaims. You probably get a reasonable comparison if you apply Knuthian programming (all memory allocation done by the user in a preallocated fixed size arrays, do-it-yourself structures including byte packing, using a compiled language on an address space big enough to access the entire array) but the main thing you will find is that compiled languages are faster than interpreted languages: indeed, the code generated by compilers may be extremely similar. Recursion is a bad (or good) example: some languages have support to restrict the stack, especially tail recursion. See, for example, http://home.pipeline.com/~hbaker1/CheneyMTA.html If this is the type of think the Shootout wants to measure, fine. Personally I feel that most languages have their strengths and weaknesses. Their designers have made specific choices as to the natural type of problem the language will solve. Solving a problem can result in quite different approaches rather than using "the" algorithm, and programmer ingenuity is not to be discounted. A good example is the most recent Project Euler problem (#155). (In this contest, you have the choice of algorithm and language. You are supposed to get the correct answer and, for extra credit, get the time down to less than 1 minute.) The table gives the language, code size (characters) and time (mm:ss) for the solutions discussed. Python 585 10:00 Mathematica 246 6:00 C 2390 0:31 J 82 0:36 Java 2376 0:20 Delphi 0:04 Solvers used quite different algorithms, in general well adapated to the language. The Python solution was weak, however, better Python programmers have reported struggling to get the time down. The Mathematica and J solutions were essentially identical. The C solution was weak, and I am sure we will see better solutions, well below 10s. The Java solution was impressive in timing for an interpreted language. The author exploited Java's collection classes, especially HashSet, and used a good gcd algorithm. The Delphi solution has not yet been posted, but is by a programmer who makes a point of performance, mainly through memoization and reduction in strength techniques. He had also seen the problem earlier than a couple of days ago. Best wishes, John ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
