[REBOL] Re: language shoot-out :-)
From: jan:skibinski:sympatico:ca at: 5-Nov-2002 13:32
Joel,
> >
> > Well, the Ackerman function is a sick function, specificly
> > designed to defeat the tail recursion elimination..
> >
>
> Please allow me to disagree slightly; the point here is just to see
> how the different languages being stress tested handle deep recursion.
> This is an exercise in language comparison, not in programmer work-
> arounds, so modifying one or more of the tests to circumvent some
> language-imposed limitation really *is* "cheating", as you put it.
Not to overheat the discussion.. take it easy.. I was obviously
teasing in part.
But I have some problems with Ackerman per se. As you must
have noticed from the second part of my previous post, any
language and any implementation must fail sooner or later
on ack 4 family. From this perspective this function is
"ill conditioned", or "singular" - as some matrices are.
Your statement "this is exercise in language comparison" is
not quite accurate: it looks like this is in fact an "exercise in
language implementation comparison". Case in question:
GHC vs. Hugs. Both use Haskell 98 (classical, frozen standard),
but GHC passes the Ackerman test just after Ocaml, while Hugs
probably not. Only people deeply involved with GHC know
exactly what sort of optimization the compiler is doing to
re-write the naive recursive code. But you obviously realize this
since you elaborate on this point a bit in another post.
I have known and watched the "shootout" page for more than
a year now. But frankly, I am not sure how useful it is due
to:
+ A purpose. What does it suppose to prove? Some languages
are good for some tasks, and bad for some other tasks.
+ Different implementations of the same language
(Haskell has three: GHC (GHCI), NHC, HUGS )
+ Missing tests (for example, there are six missing tests for Haskell)
+ Quality of submissions.
+ Choice of tests.
+ And probably many more...
There is quite interesting programming contest,
running within the framework of International Conference
on Functional Programming, ICFP. This year's contest page
is hosted by OGI, Oregon, US:
http://icfpcontest.cse.ogi.edu/
For several years, the winners were using mostly Ocaml, Haskell,
Cilk, etc. In past years the teams with imperative languages, such
as Java and C/C++ were doing very poorly. Python, Smalltalk, Ruby,
etc. were also way, way behind.
This year's theme was about simulated robotic games. The winner
was again an Ocaml team - this time from Japan. But this year,
the second place was taken by a C team (surprise, surprise!),
while most of the other functional teams simply failed.
There are many justifications and excuses for this, but the basic
question is this:
"Is it really about the languages or about a quality of participants
an a bit of luck?"
Regards,
Jan
