Go Haskell! (was: [Haskell-cafe] What *not* to use Haskell for)
claus.reinke at talk21.com
Tue Nov 11 18:42:57 EST 2008
> Do you have an example of a mutable state/ IO bound application, like,
> hmm, a window manager or a revision control system or a file system...?
If you're looking for a challenge, how about this one (there used to
be lots of Haskellers into this game, any of you still around?-):
The specification is the numbered list at the end of the message, or in the
zip file with the Java example implementation (README). Actually, the
interesting part from a performance perspective doesn't even require GTP
or AMAF, just implement the random legal playouts for a 9x9 board, do
a loop over them, keeping some basic win/loose/game length statistics.
Can you complete that in competitive speed, preferably from the specs,
without just transliterating the low-level Java code? I won't tell you yet
what typical playouts-per-second-per-core numbers are floating about
for "lightly" optimised code; try to improve your code and say "stop,
this is good enough" before comparing with the Java bot runtimes.
You'll probably have no room left for any high-level operations, ending
up with mostly imperatively threaded array manipulations in a loop that
is expected to be run several thousand times per real-game move (the
idea being to run lots of dumb, but legal, simulations to the end, where
evaluation is easy, gather statistics, then choose the move that seems
to have the most potential). Bonus points if you can preserve any of the
high-level advantages of working in Haskell (such as easy debuggability,
because there will be bugs, especially if you can't afford to maintain
redundant information representations) without sacrificing speed. (*)
As specified, the bot won't win any tournaments - it is the starting
point (or remote ancestor) for the current champions, with lots of room
for algorithmic improvement, not to mention actual game knowledge,
tree search and parallelization (the configurations being used for tournaments
and exhibition games are highly parallel). The reference spec is a recent
effort, meant to provide a first milestone for aspiring Go programmers
to compare their code against, while also inviting programmers to
to show how their favourite language is eminently suitable for Go
programming (without sacrificing performance!). There are versions
in Java, D, C++, C#, and C around somewhere, possibly others.
But: please, no language evangelism on that mailing list! Those people
seem decent, peaceful and open-minded (there's even a Haskell spec
of a simple rule set here http://homepages.cwi.nl/~tromp/go.html ).
And some of them have years (a few even decades) of experience,
much of which is made available in the mailinglist archives and
bibliography (pointers available on request - if you wanted to get
serious about playing with Go programming, you'd be expected
to mine the archives and bibliography, because just about anything
you'll come up with in your first few months will have been discussed
already;-), in spite of commercial interests and ongoing competitions.
They are already tired and wary of useless language wars (who isn't?).
(who has been wanting to write a Go player ever since he
had to decide between research and learning more Go, either
one trying to eat all available time and then some; perhaps I
should write a researcher instead, and return to playing Go?-)
(*) it would be nice if the sequential baseline performance of
functional Haskell/Ghc arrays would be better, btw; that would
make the ongoing work on parallel arrays much more interesting.
More information about the Haskell-Cafe