--- Begin Message ---
Hello,
To my surprise I could not post to the list, since it thinks I'm not
suscribing to this list. Probably because I'm using a forward account while
I'm working abroad.
Could you please be so kind to forward my message to the computer-go list
and ask them why they're rejecting any posts from the 'outside'. Is there
any reason for this group to be closed?
Thanks in advance,
Mark Boon
I've been reading this tread with considerable interest. So far I didn't
even have time to post a message, let alone doing any work.
For a couple of months I've been thinking about how to make a framework
that could be shared by many people so that they don't have to replicate an
enormous amount of work. I've even implemented a set of interfaces in Java
that implement a simple go-board and a move tree package. This was made in
such a way it's even not specific to Go, but could be used for other games
as well.
Sharing code is rather difficult and most of the time that is not even
desirable. The one file that I saw pass by had a lot of constants defined,
but every implementation of a Go program is going to have it's own
definitions for those. I agree with an earlier suggestion that defining
interfaces is far more important.
Those who depend on Go software for a living tend to shy away from sharing
code, and those who make their living otherwise usually don't have time to
contribute, the eternal dilemma. Since I don't depend on Go software as my
income, I thought about sharing some of my knowledge. Not in the sense of
giving away any source code, but in a different way. I think it would
greatly help if there were a common platform that is used to develop game
software (not only Go, it could also be chess, checkers etc.) One of the
ideas I had was to make a web-object of Goliath using CORBA and use the
framework I mentioned above to incorporate it. Without sharing a single
line of code, this could be an enormous boost to Go programming. Imagine
you have an automatic sparring partner. Or even better, use it to generate
moves in situations your fledgling program doesn't handle yet. This way new
ideas can be tested much more quickly without sharing a single line of
code. And that is just the start of it.
Let me end with a bit of Goliath history. This might have changed by now
but Goliath at the time had I believe by far the fastest ladder-reading
algorithm.
This algorithm was the result of me and a friend of mine having a small
competition who could make the fastest algorithm. This was after my friend
noticed the first version of the algorithm I made seemed rather slow. For
several weeks we tried to think and implement the fastest algorithm,
testing it on a couple of everyday ladder situations. After each test, we
would swap ideas and have another go at it, until the algorithms seemed to
converge to a certain lower limit.
In the end the algorithm was a few dozen times faster than it was
originally, without sharing a single line of code. This all resulted just
from having a common goal and a common environment to work with.
As of the eternal language discussion, I find Java a much more suitable
language for Go programming than C++. As for the speed considerations,
Goliath runs about two times slower in Java than it does in C++. As Java
development environments mature, this will even get better still I'm sure.
To prove my point, visit the following web-page "
http://people.a2000.nl/mboon"; to find a Java version of Goliath. I'm sure
that you'll find it's speed of play very satisfactory. (Although it takes a
while to download.)
Mark Boon
--- End Message ---