>As for me, i'm really NOT interested in knowing "what langage is good for go >programming". That's simply not a question i can ask myself, nor anyone else. > This question doesn't make any sense for me. Still if someone can get the >"standard light playout" right in less than 10 code line, and they are very >understandable lines. I would be very happy to see it. But it would never >mean for me that, "this language is BEST". Even if the peformances are >optimal there. I think 90% of the "this language is the best" debate gets it's >root in some affective part of the people engaged with it.
As someone interested in programming languages, I cannot resist to comment. True, language advocacy tends to be boring at best, and -in its extreme forms- tends to be pursued not by the language designers themselves. If they have any experience at all, they are quite willing to let their language speak for itself, and quite open-minded, both toward other languages having good points and toward their own language having weak points. Converts turned evangelists are often as embarrassing to "their" community as they are to their target audience. You might get a little more out of the question if you change your perspective a little: ask "what language is good for Go programming?" not with a view on what general- or specific-purpose languages are out there, but with a view on how you would like to express your thoughts about Go. In this particular case, representations seem to play a fundamental role: I didn't want to think about details or optimizations too early, but I found it impossible to think about the algorithms without choosing suitable data representations (too many details to keep in mind if the representations were unsuitable); once I got the "right" representations, the algorithms were straightforward, and whenever added algorithms started to get complicated, it indicated a need to switch to a better representation. So, once you've got your representations (sets/bitmaps, arrays/hashtables, etc.) implemented in libraries, the programming language itself may not matter much any more (recursion simplifies things, but whether one recursively collects sets of liberties in imperative, functional, logic, or object-oriented code may not make much difference - even assembler might be manageable, given such libraries, just that it might doom your code when you move to a different machine in future). But in thinking about a consistent set of representations suitable for Go programming, you're effectively deciding on a language to use when talking about Go programming issues. Being aware of this, the question "what language is good for Go programming?" may turn out to be a little more useful and interesting. An unsuitable answer results in complicated code, which is hard to think about and even harder to get correct; a suitable answer results in simple code, which can then be embedded into many of the popular general purpose languages. Claus _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
