[Fwd: Re: [computer-go] Event-driven programming]

["Robin Kramer" <robin@xxxxxxxx>]

-------- Original Message --------
Subject: Re: [computer-go] Event-driven programming
From: "Robin Kramer" <robin@xxxxxxxxxxxxxxxxx>
Date: Fri, January 16, 2004 2:36 pm
To: <drake@xxxxxxxxxxxxxxxxx>

1)Just like the stories of Casey Jones and Gary Kasporov, the question
is not can I build a machine that can beat any individual, but can we
build a machine that can beat any individual.

2)Having programmed programs for the Buzz Audio tracker project, which
has a master module, which allows the machines to connect and process
effects or synthesize sound.  The core programer won't release the code,
"because it is programmed poorly", and it is programmed poorly crashing
all of the time and causing people to loose their songs.  It does work
sometimes, but for the most part people try to recode it, but there is
so much code that supports it that things only get worse.

3)There are certain advantages to being part of a team which has the
best Go playing program in the world, weather they are monetary or just
glory.

Sincerely,

Robin Kramer

> Wait a second ... why are we drawing up a contract?
>
> On Friday, January 16, 2004, at 11:43  AM, Robin Kramer wrote:
>
>>>> One other question, will some modules be able to generate events?
>>>> Will modules be able to set up their own event servers to
>>>> incorporate information from other machines(i.e. if two modules
>>>> could use
>>>> information
>>>> about ladders, maybe a joseki and a tesuji module will they both be
>>>> able
>>>> to use a module which reads ladders?)
>>>
>>> I'm not sure I understand your question.
>>
>> I have been reading about contract programming, and the idea is that
>> a program specifies an interface on which other programs depend, so
>> in essence a program specifies a contract between individuals.  Once
>> you program a program to the specified contract, that contract cannot
>> change.
>> If you want to program additional features, then you have to write a
>> new
>> contract and make it public, so that other developers can take
>> advantage
>> of the new features, but also maintain the original contract.
>>
>> Lets draw up a contract.  The master module must at least have these
>> properties:
>>
>> 1)Open Source, and cannot be redistributed under a commercial
>> license. 2) Well documented, with interfaces and templates
>> demonstrating any functionality.
>>
>> I am open to other contracts provided there are other benefits.
>>
>> Sincerely,
>>
>> Robin Kramer
>>
>> I have got to stop reading the Microsoft COM specification.
>>
>>
>> _______________________________________________
>> computer-go mailing list
>> computer-go@xxxxxxxxxxxxxxxxx
>> http://computer-go.org/mailman/listinfo/computer-go
>>
> Peter Drake
> Assistant Professor of Computer Science
> Lewis & Clark College
> http://www.lclark.edu/~drake/



_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://computer-go.org/mailman/listinfo/computer-go