On Nov 21, 2007 7:06 PM, Don Dailey <[EMAIL PROTECTED]> wrote: > You see to have very old-fashioned ideas about the whole programming > philosophy. You take the view that a project like go is a fixed > static "task" and that you must optimize the programmers time in typing > in code. And then you are "done." And since it takes many man > hours, it doesn't matter if it takes 10 seconds to find a move instead > of 1. After all, waiting an extra 9 seconds is nothing compared to > the hundreds of hours programming this task. Or you can wait 5 years > and that 9 seconds is now 1 second.
You can look at this from a completely different point of view and come to the opposite conclusion. Because creating a Go program is NOT a static task, it means that you can't just code the program once and be done. You will constantly be revising old code and writing new code. Therefore, it seems like writing in a language that is fast and easy would be beneficial. Suppose I have a Go program written in a language that is fast to write and slow to run and you have one in a language that is slow to write and fast to run. Right now, your program is faster than mine and therefore better. Now let's say a new technique is developed that will improve our programs. I can add this technique into my program in, say, two weeks, but it will take you 2 months. So for a month and a half, I have a better program. By the time you finish your implementation, it's possible that another new technique will have been developed. From that point of view, it seems like it is the person with the slow-to-code, fast-to-run language that will always be playing catch up. It seems like it really comes down to the programmer. I don't think any language is necessarily faster or easier to code than another one, it all depends on the experience and skill of the programmer. > This model might be reasonable in a corporate environment where you have > different priorities, but the whole POINT of a GO program is to make it > as strong as possible. That may be true if your goal is to have the strongest Go program in the world, but another completely legitimate goal is to develop new techniques and algorithms to address the problem. In that case, it doesn't really matter if your program is slow. Colin _______________________________________________ computer-go mailing list [email protected] http://www.computer-go.org/mailman/listinfo/computer-go/
