Author: Daniel Clausen
Date: 09:21:16 04/12/02
Go up one level in this thread
On April 12, 2002 at 11:46:54, Miguel A. Ballicora wrote: >Good programmers take good decisions. Those involves readability, flexibility, >simplicity and good design. Curiously, speed comes as a consequence. Because if >you have a program that is readable, flexible, simple with a good design you >will be able to modify it quicker. Complexity could be good for tomorrow >but terrible for the day after tomorrow. So, complex changes should be adopted >if they are really worth it. If involves lack of flexibility, you might want to >toss it out. Because the little % that you gain today, will get in your way in >the next optimizations that you do next month. Or even worse, you won't even >notice it. You might try a new ordering system and or a new selective idea >and the 5% that you think you won now is -5% (but you dot test it anymore >because the code become rigid since other things depend on that, so you do not >know that you lost 5%). Very well said! A programmer who writes the perfect piece of software in one go is not a just a good programmer but a godlike programmer. (very few exist - I mean godlike programmers not gods; I don't want to start a religious war here ;) A programmer who knows the first go won't be the best and codes things readable/flexible etc so he/she's able to make changes later is a good programmer. Similarly, a good programmer optimizes when he/she knows what part of the code is time-critical. (more than not people's guesses are completely wrong on this...) Also it should be a part which doesn't change tomorrow.. For example, Sinan (my engine) copies the whole board structure for undoMove(). But as long as Sinan's branching factor is 20 and the doMove() is changed every 2 weeks, it would be pretty dumb to invest time in a undoMove() function. IMHO, YMMV :) Sargon
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.