[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [computer-go] Re: which programming language is better

On Sep 11, 2004, at 9:03 AM, Arend Bayer wrote:


On Sat, 11 Sep 2004 Compgo123@xxxxxxxxxxxxxxxxx wrote:
Recently I got some new ideas and decided to re-write my program. So this
subject has some meaning to me. My experience tells me that the easiness to debug
a program is of great importance. The most often met problems are the memory
leak or illegal memory reference. Some of the problems hide very deep. They
were found most of the time when I do a large number of search. For example when
I search 1 million nodes the program is fine. But it hangs up at about one
and half million nodes. Made it vey difficult to debug. So there should be a
convenient way to check memory leak and to debug.
If you are developing under Linux, I strongly recommend to try out
valgrind. It can does all of the above, plus a very fine-grained
checking of uninitialized memory access.

Having said that, my experience with GNU Go is the same as has been
described by, I think, Chrilly Donninger: Very few of the bugs are
language specific.
True, but C makes it ever so easy to do stupid things, and harder (or at least
requires extra steps) to do careful things. C is like a very sharp knife ... a whole
bunch of experts strongly prefer its efficiency, but it is easy to cause problems
if you are not careful.

We had a tough bug to find just last week when checking sgf files for duplicate
games. The guy who wrote the code was not aware that a pass was represented
by a space between the brackets, and as a result the code indexed an array out
of bounds. The result was that a move was changed for a game from another file.
It took over an hour to track that down.

Yes, complier options can be set and code can be written to check, but I think
that the options should default to the things that make early development
and debugging easy, and it should take extra effort to streamline and turn off
checking to get extra performance later in the development cycle. It really is a
bother to wrap everything in small snippets of code to assure that every
variable is within the expected bounds. To do this, with asserts or whatever,
is good programming practice in C, but is a distraction from thinking about
the desired logical flow of the program, and then a bother again when you
want to go back and pull it all out because you think you have confidence in
the stability of the code.

But we keep using C anyway. Never underestimate the power of inertia.

Cheers,
David


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