|
>There is also the fact that these systems were
mostly designed and implemented before I was even born. Back then,
>most designers probably didn't even hear about modular design,
object-oriented programming, or perhaps even >something as simple as code
reuse. Every big old system is a mess because of that.
Dear boy, we old guys were also not completly stupid in these days. Things have improved somewhat, but 1 million lines are still a big nasty monster. E.g. also in a modular design one has to define the interface between the modules. Nobody knows in advance exactly how this interfaces should be. It is like an earthquake, if one detects during development, that the defined interfaces are not practical. One consequence is: Everyone avoids such changes, although no one is happy with the interfaces and has the fealing that there should be something changed. This is only done, if a major change is unavoidable. A simple example: In a big system for process control I worked
with the meaning of a parameter was implemented against the specification.
"Up" was in interpreted as "down". Some day someone detected the bug. But
the other developers had learned to live with this behaviour and fixing the bug
broke everything. After very long discussions it was decided to leave the module
as is and change the initial specifications.
The point here is "after long discussion".
It is well known, that the average producivity in such systems
is about 3000 lines/man year or about 9 lines/day. One can ask, if the
programmers are drinking just coffee. Yes they drink most of the time coffee.
This is what you do when you sit in a meeting. Or you write some reports or
answer some emails from other project members. Doing programming becomes a
minor point in these projects. Yóu do it at the evening or when the boss is one
holidays and you have finally some time were nobody disturbs you.
These limitations of big projects are deadly for a
game-playing programm. Doing game development is essentially a trial and error
process. Even after 10+ years of professional chess programming, I usually do
not know the full consequences of a new feature. I have just to try it
out. Only 1 out of 10 ideas are then really an improvement.
There is also a close interaction between the parts. E.g. If
you implement some selective search techniques like the NullMove, the
evaluation function and/or the quiesence search must be clever enough do detect
threats. You can seperate the parts on the syntactic level, but you can not
define away this semantic dependencies.
Best Regards
Chrilly Donninger
|
_______________________________________________ computer-go mailing list computer-go@xxxxxxxxxxxxxxxxx http://www.computer-go.org/mailman/listinfo/computer-go/