Don Dailey skrev:
On Tue, 2008-11-04 at 20:13 +0100, Dan Andersson wrote:
If one takes the position that bugs have a pretty significant impact
on
the strength of a program (A position I agree with) one could be
pretty
forgiving about the speed of execution of an algorithm if it is
written
in an expressive language with a top of the line type system since it
delivers a double whammy to bugs. It actually doesn't seem like a bad
move to be half or third speed to the top of the line speed monster
then.
It's possible to even write C code without too many bugs if you use good
programming discipline, lots of assertions and so on.
However, what is important when we talk about the ultimate program is
the "release version" of a program. It may take a lot longer to get
the bugs out, but this cost is payed for many times over by every user
of your software. The reasoning about developmental time vs
execution time only applies in certain situations. If you are writing
a program that you only run 1 time and you don't care how long it takes
to finish (within reason), then of course it strikes with a vengeance -
you want the easiest system to program with. It's also cheaper to buy
computers than to buy programmers, so you want something that maximizes
programmers productivity. But in some cases, whatever time you spend
up front developing will reward you forever. For instance if you are a
commercial games developer, the end user will not appreciate that your
product sucks because you chose to make it easy on yourself.
One approach is to build your prototypes in whatever language really
works for you, then build the final release version in something fast.
I believe that if you know exactly what program you are writing - and no
experimentation is involved, then it doesn't take long to build it in
any language that you are familiar with.
I built those reference bots very quickly, especially considering that I
didn't know how to program in those languages. But I had a definite
specification. I wasn't trying to figure out what to write, but I
knew exactly what it was to do before I started.
Several other lines of reasoning might lead to different choices
also.
Of course, it's all about what it is you want to maximize.
Interactive development and testing and/or superior visualization
frameworks might lead to breakthroughs in pruning/exploration v.
exploitation ratios/patterns/generalization techniques.
I agree there. You need to actually spend a lot of time up front no
matter what language you are using building tools that will help you
visualize, assess, instrument and evaluate versions of your software.
But the language choice could very well lead you down more (or less)
productive pathways.
- Don
Writing bug free C code aside. Deciding that it is gainful to do an
"Ultimate" or release version of a program is not the easiest thing. If
your project is open ended in time the time spent might never be
recouped in the long run. Each premature release will set you back from
the ideal maximal + final optimized release. It might not even be if you
have a project with an iron clad mission statement, road map and clearly
stated goals and stop date if a maximized playing strength is the
primary goal.
Hope the thoughts expressed are coherent. I'm tired beyond belief.
/Dan Andersson
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
