[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: computer-go: gnugoclient 2.0
From: Heikki Levanto <heikki@xxxxxxxxxxxxxxxxx>
On Fri, Aug 03, 2001 at 05:03:14PM -0400, Don Dailey wrote:
> Whether a program has "undo" or not isn't really a big deal. But in
> my opinion the real issue is getting this very basic feature
> documented right away.
A standard is complete not when there is nothing to add, but when there is
nothing to remove!
Hi Heikki,
I am not looking to be fashionably minimal and think we would be
making a mistake to throw out all commands not directly needed to play
a game, like "quit", "komi", "boardsize" and "version."
The goal is to have a small but practical set of commands. This is an
engineering issue, not a philisophical thing. GTP is a communication
protocol designed to support Go engines talking to any kind of Go
utility and as such it's almost ludicrous to view "undo" as an
"advanced" command.
It doesn't take a great deal of imagination to see how powerful and
useful such a command is, and yet so easy to implement.
There was a post a few weeks ago about user interfaces that I will
quote here, and it really hits the nail on the head. In my opinion,
our standard should be small, but big enough to address the few very
basic issues this poster mentioned:
> now i want to mention how i got into that. it had nothing to do
> with playing go via a server, all i wanted to do is play against
> gnugo on my machine. you can do that with cgoban, but that does not
> let you continue to play a saved game. also whenever gnugo makes a
> particularly stupid move, i want to find out why and then i want to
> force gnugo to play another move. all this you can do with
> play_ascii, but that has a lousy display. so all i did was ...
To me, this is just not right. I can't see going to the trouble to
define a standard that doesn't support any of this.
Am I being crazy or too optimistic? How can anyone consider "undo" as
being an esoteric or highly advanced feature?
By the way, you did go on to consider other possibilities like having
hierarchies of sets and provisions for ignoring commands. Yes, this
is probably need at some level, but I believe it's important to make
sure the FIRST basic standard draft is complete enough to do a
reasonable job, and not a seriously crippled and limited subset of the
commands that people "really want."
Don