Re: OpenGo Suggestion as Re: Eureka

[David Mechner <mechner@xxxxxxxxxxxxxxxxx>]

I've always been skeptical (to put it mildly) about code sharing
projects that conceive of a go program as comprised of a bunch of
interchangeable modules. It just doesn't work that way - "traditional"
go programs are necessarily tangled nests of implicit assumptions and
hidden logical dependencies. Go programs just aren't modular.

The information in a program, comprised of patterns, algorithms, and
data structures, is built around hidden assumptions (hidden except for
whatever informal description exists in comments), around the precise
needs of a other algorithms in that particular program. For example, an
"eye" in our (Tim's and my) program is a /potential/ eye - even a very
weak eye counts as an eye as long as it might someday become an eye.
That's to accommodate the binary logic of our life & death algorithm -
ignoring a lot of details, if a group doesn't have two of these "weak"
eyes, it can be considered dead and we can stop reading. Another go
program without this peculiarity would probably want to know only about
definite eyes or likely eyes, or maybe to have a rating for each eye
saying how likely it is to end up "real." Essentially our eye patterns
and data structures would be useless (or worse) for anyone else.  The
same problem at another level: our eyes have "centers" and "borders."
All the other parts of our program that ask eyes about centers and
borders would break if we somehow plugged in a different eye module that
didn't organize eyes that way. And what if they did, but they meant
slightly different things (do you know what I mean by center and border
exactly enough to write code that uses them?)

That being said I think there are a few elements that account for a good
deal of the startup time for traditional go programs that might be 
written generically enough to be shared, and which might shave a couple
of years (or more) off the startup time for new go programmers. They
are:

0) GUI (for graphical display of data structures & pattern editing)
1) reversion system (& revertible container class library) 
2) pattern matching system 
3) low liberty tactics search engine
4) ko detection/zobrist hash implementation

Or anyway that's all i can think of offhand. I think the pattern
matching system would be the most challenging both in terms of
programming and design, i.e. getting something that's both general
enough and efficient enough to be useful to a lot of people. It would
probably also be the most useful.

It might be an interesting exercise, at least, to kick around design
ideas for this kind of thing. Who knows, maybe someone will actually
write & contribute code for some of these things.

-David

-- 
David A. Mechner            Center for Neural Science
mechner@xxxxxxxxxxxxxxxxx         4 Washington Place, New York, NY 10003
212.998.3580                http://cns.nyu.edu/~mechner/