Hi Raymond, The point I'm making is that you must focus on what's relevant. If you are trying to win the title of world championship go program, then maintainability of code is LOW on the list of what is important. In a corporate environment it moves close to the TOP of the list of what is important.
Experience in a language is a factor, but nobody refutes that properly coded C is fastest (next to properly code assembly) and if performance is your goal, then anything else accepts some compromise. That compromise may work well for a particular individual and may even produce a stronger program for them, but it's still a handicap. For example, Mogo probably could be coded in Java and still (probably) be the best 9x9 program. If so, then it would be the best despite the fact that it was coded in Java, not because of it. They would have had to overcome a good bit of performance handicap. There are some tennis players that could beat me with one hand tied behind their back, but that doesn't mean it's the way to go. They would have to beat me despite the fact that one hand was tied behind their back. A player close to my level would not have a chance with this handicap because it is in fact a handicap, no matter how you cast it. My feeling is that the engineer who starts his GO programming project in a high level language is not going to be able to compete with the C programmer, even if he is given the extra hardware to equalize. I say this because he has already proven (in some sense) that he can't make good decisions and you can be reasonably sure that he will make more bad decisions. For example you can be relatively sure that he will not favor doing things fast if he has to write ugly code - after all he has already made choices that indicates he values high level thinking and nice code over low level efficiency. In fact it would be rather silly if he used a high level language, but then resorted to performance tricks. I don't say this to be ugly or to be critical of java or other programmers. These languages are fine choices as long as you don't believe you are writing a cutting edge high performance go program. I am rather curious, which CGOS program that is NOT in C/C++ or assembler is highest rated? Despite all the hype about expressibility and code maintainability I would guess that the best programs are in C, then perhaps Java (since it's relatively fast) and that the weakest are in the "highly productive" dynamic programming languages that are slow. By the way, I'm a huge advocate of Ruby, one of the slowest languages! I love this language as well as Lua and others. However, common sense must prevail. It's just insane to reach for Ruby to produce a high performance Go program. And to a lesser degree Java. - Don Raymond Wold wrote: > Don Dailey wrote: > >> For that, C currently appears to be the best choice. This in not >> just my opinion, there is empirical evidence to support this claim. >> >> > The problem with "empirical evidence" is that you don't get the very > much needed "all else being equal". The people that code in C (and get > great speeds for the algorithms where speed means a skill increase) > are people that know C best, that have years of experience in it, and > also, people that have a different attitude towards /how/ to solve > problems, /what/ algorithms to write. I suspect that Java coders, and > especially Haskell, Lisp, etc. coders, are people with significant > less experience in those languages; partially because you need a lot > less knowledge about programming to get started and get anywhere, but > also because these languages have something of the hype about them*, > and might be chosen as the language merely for being the latest > language, or the highest-level one, learned so far. And you think > differently when coding in a higher level language. It might well be > that the slightly different mindset of low-level programmers is more > suited for go. It might be that we /need/ a domain specific language > for go. > > But none of this means that the /speed of execution/ is the crucial > factor, or even an important one. Yes, perhaps the same algorithm in > Haskell is ten times as slow as one in assembler. But does that mean > that if you give a Haskell coder ten times as powerful hardware, that > he'll be able to compete with the C coder? I'm not so sure. > > The maintainability aspect is not to be laughed at either. Once you > get above a certain size in complexity of the program, having it in C > from the start will mean a much greater inertia against expanding and > experimenting with what you have. And I suspect go programms will have > to go above this to beat the current set of algorithms. As seducing as > the idea that there's an elegant solution is, I don't think it's > realistic. And then we'll need the added clarity of high-level > programming. > > *) Without that meaning they're worse languages for being hyped, or > being picked up for word of mouth value only. > _______________________________________________ > computer-go mailing list > computer-go@computer-go.org > http://www.computer-go.org/mailman/listinfo/computer-go/ > _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
