[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [computer-go] Moyoman, a Go playing program
On Jul 8, 2004, at 5:13, chrilly wrote:
>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.
First: Don't call me Dear Boy. Or would you have me call you Old Fart?
Second: I've worked on large, old codebases myself, so I know what I'm talking about.
Third: Stupid or not, old code is just more bloated than new one (even though it's hard to believe sometimes).
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".
That's the reason why they never fire old folks: These projects are always obscure and dramatically underdocumented. Therefore nobody dares to fix bugs, let alone rewrite anything. I've got a pretty clear view of what it is like while digging into the NetBSD kernel.
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.
I know what you're talking about.
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.
This has nothing to do with monstruous codebases, but with the complexity of the task itself. I'm currently managing 2500 lines C++ code SAT solver and it's just that bad. There is no way such things can be broken further down, at least not into completely independent components, nor can behavior always be predicted as you already pointed out. Still, badly managed code can easily make things far worse.
One very dumb example:
Before I even started coding it, I realized I would need intrusive reference-counting smart pointers (quite unusual, I know). While in old code memory is managed more or less manually and is therefore plagued with memory leaks, I had no such concern because I thought of the complexity of the task in advance. Given I use hundreds of these pointers, I guess I saved thousands of lines of code and hundreds of hours of debugging whle writing far more readable code since trivial memory management has been taken out of the core engine. I've never seen old code designed that way, partly because it was hardly possible at the time, partly because nobody cared until it was too late.
[I wish I had had that much foresight for other things however... It would have saved me a lot of trouble.]
Besides, I don't see how this is a "limitation"; would you really have a 1M codebase for a chess program? What for? Even in an era where the average clock program takes tens of thousands of lines of code and requires a hundred megs of RAM, this is still ludicrous.
--Martin
Best Regards
Chrilly Donninger
_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/
_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/