I think we are missing the point of programmer productivity with higher level languages. High level languages MIGHT improve the speed at which you write code, but usually that is a minor concern. In computer GO, what you want is the pathway that gives you the best programs in the least amount of effort.
For that, C currently appears to be the best choice. This in not just my opinion, there is empirical evidence to support this claim. Take a close look at the very best GO programs in the world, and I doubt you will see Ruby and Python programs. I doubt you will see Java programs. All of these programming languages, as wonderful as they may be and most of which claim dramatically increased productivity, simply are not "producing." Most arguments for using these languages are nonsense. They focus on only one aspect of the total picture - how fast you can write bug-free code. Some languages are clearly better than others at that but the biggest factor by far is the programmer herself. Many say, "it's just not worth a few percent speedup to code in a low level language." I hope you realize that "few percent" is probably in the best case around 50%. We could argue about the exact number, but the fact is that you take a substantial hit programming in Java (for instance) and that is not even a high level language. Computer Go is still in the dark ages but is gradually emerging from it - it's starting to be appreciated that 50% represents a significant strength improvement. That probably means it's "low hanging fruit" - in other words you are probably going to get the most improvement for your programming time developing and programming in C. And yet many will say, but I would rather spend my time improving the algorithm in a language that makes it easy to express my ideas. I might be throwing away 50%, but I will quickly make up the difference with my vastly improved ability to experiment and express my wonderful ideas. One might even argue that using a low level language like C is actually "inhibiting" their ability to forge ahead. My experience in computer chess is that the people who think this way, never catch up. I call this the drunken sailor approach. The metaphor is the drunken sailor who blows most of his paycheck the day he gets it. He does this, because it seems to him like a lot of money. When there is a lot of money in your pocket, it's easy to spend it frivolously and then tighten up when you are almost broke. Computers are fast. You don't mind taking the 2 to 1 hit (or whatever it is) for the extra luxury of programming in a high level language. However, this mentality doesn't stop here. If you are thinking this way, chances are that you take other shortcuts for the "long term good". The problem is that you never stop taking the hit. You say, in 18 months computers will be 2X faster, so it "doesn't matter." This is the stupidest thing I keep hearing. In 18 months you will have a faster computer, but your program will STILL be a crippled program that sucks. Getting a faster wheelchair doesn't stop you from being crippled. The drunken sailor borrows money thinking that his next paycheck will cover these debts but forgets he will have to borrow money again. When I develop my go program, the vast majority of the development time is spent by the computer, not me. I need to optimize the computers time, not my time. Whatever the program can do in 1 minute, I would like to see happen in 30 seconds. If I had a network of workstations my productivity (as measured by program strength) would improve significantly because I could try a lot more thing in the same amount of time. But even if I had such a network, I wouldn't willingly cripple it by throwing away half the power. In fact, the whole concept is not to optimize what YOU do, it's to optimize what the computer does. If you are not stingy about the performance (playing strength) right from the start you are already starting from the wrong mentality. That's probably why the best programs are in C or assembler - these programmers see performance as part of the overall whole - not something that is "in their way." They don't romanticize their language or the tools they use, they are focused on the problem and tend to make the most logical choices, not the sexiest ones. My advice when this question comes up (which language for go programmer) is to first ask, what do you hope to achieve? If you want to build a high performance go program, anything other than C or assembler is like tying your hand behind your back. If you do this only as a hobby and have no aspirations (just for fun and pleasure) then by all means, you will be much happier in a high level language. - Don Raymond Wold wrote: > Nick Apperson wrote: > >> But, to be fair, I totally agree that compiling python or ruby would >> give >> you noticable speed gains. And as always, speed comparisons are only >> useful >> in context. In terms of go programming.... if you are prototyping use >> whatever the hell you want. If you are finishing something off, >> don't waste >> my time with any of those slow languages (that includes java and c#). >> >> > I would posit that coding go, we are _always_ prototyping. > _______________________________________________ > 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/
