Re: [computer-go] Lisp time
The same facts of the invalidity of benchmarks continue to surface, and it's well understood that they can be misleading - but for me the very simple truth is straightforward.I have tried many different languages and in every case so far it has not turned out unclear, C has always won. So yes, it's possible to draw the wrong conclusions and yes benchmarks will always have flaws in them, and yes it's more important to optimize the algorithm and yes certain optimizations work better on some CPU's than others and ... so on and so on. This is all true. But I have found so far that the performance advantage of C is so overwhelming that my first unoptimized attempt in C produces a faster program than in other languages. Stefan has said that C is a lousy performance language and that it's only fast if you go to great lengths to make it so.That is completely contrary to my own experience. One of the reasons I do performance coding in C is that I can produce faster code on my first try than I can with any other language.Again, contrary to what Stefan thinks, I have found that if you want fast code in any language you have to work at it and that usually means you have to ugly it up a little.I haven't seen that any language is immune to that. One thing is really clear to me. I will spend less time writing C code (without worrying too much about optimizations) that I will spending an enormous time trying to make one of these ideal languages run almost as fast. Yes, in theory there may be a couple of languages that have potential to beat C. But that is no good to me now.When theory becomes reality I will be the first to change over. As has been mentioned before, the amount of effort gone into C compiler technology is probably responsible for this.I seriously doubt any other language has had so much effort devoted to squeezing so much from them. If that had been the case then C probably would be a close second or third in speed. There is also something else to keep in mind. There is not even a discussion when it comes to the vast majority of languages because we are talking 5-100 X slower than C in most cases.A language starts to get interesting when it is within 2X factor of C.In which case it is usually almost as fast as C if you turn all optimizations off for C and all optimization on for the other language. I'm not a C enthusiast, I wish it were different. I don't like C. I continue to look for it's replacement. - Don Stefan Nobis wrote: Isaac Gouy [EMAIL PROTECTED] writes: Again, you seem happy to say they are overrated and dismiss them without actually having looked - that is not scientific! Yes, my critique is not up to the standards I measure the shootout with. But my main point is: Performance has so many (sometimes hard to recognize) parameters that's really easy to draw false conclusions From some benchmark data. If you are interested for the best performance for you task at hand, you have to do benchmarks within your execution environment and you have to construct benachmarks that really resemble your task. Different OS, different CPU, even different cache sizes, different alogrithms and so on. All these things really matter and if you change any of these parameters the whole picture may change (on OS A, CPU B compiler S for language X may be produce code that executes faster for a benchmark than the code that is produced by compiler T for language Y on the same system, but on CPU C the combination T/Y may be better). One extra problem: As far as I can see you only compare freely available language implementations (and this point is overssen by many people -- I'm a big open source fan, but more often than not there is one or more commercial language implementation that produce better results than any of the freely available implementations). These games are funny and sometimes it's even possible to come to helpful conclusions given the data. But many people I talked with understand these shootouts as hard facts, they assume language X is always better than language Y and don't take into account for example that they are developing for a Sparc cluster while using benchmarks for Intel/AMD. OK, so I would say I don't really have any problems with the shootout but with the perception of these shootouts by many people. And that's why I dislike these shootouts in general. ___ 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/
Re: [computer-go] Lisp time
--- Stefan Nobis [EMAIL PROTECTED] wrote: Isaac Gouy [EMAIL PROTECTED] writes: Again, you seem happy to say they are overrated and dismiss them without actually having looked - that is not scientific! Yes, my critique is not up to the standards I measure the shootout with. But my main point is: Performance has so many (sometimes hard to recognize) parameters that's really easy to draw false conclusions From some benchmark data. Yes, and it's really really really easy to guess or assume false conclusions without looking at any data! :-) If you are interested for the best performance for you task at hand, you have to do benchmarks within your execution environment and you have to construct benachmarks that really resemble your task. Different OS, different CPU, even different cache sizes, different alogrithms and so on. All these things really matter and if you change any of these parameters the whole picture may change (on OS A, CPU B compiler S for language X may be produce code that executes faster for a benchmark than the code that is produced by compiler T for language Y on the same system, but on CPU C the combination T/Y may be better). Yes, and people can see some of that by just by comparing the benchmarks game measurements of the same programs made on the AMD Sempron machine and on the Intel P4 machine. Some of them even read about Flawed Benchmarks http://shootout.alioth.debian.org/gp4/miscfile.php?file=benchmarkingtitle=Flawed%20Benchmarks One extra problem: As far as I can see you only compare freely available language implementations (and this point is overssen by many people -- I'm a big open source fan, but more often than not there is one or more commercial language implementation that produce better results than any of the freely available implementations). Yes, and if you had looked at the website you would know that we talk insistently about programming language /implementations/. How can we benchmark a programming language? We can't - we benchmark programming language implementations. How can we benchmark language implementations? We can't - we measure particular programs. http://shootout.alioth.debian.org/ These games are funny and sometimes it's even possible to come to helpful conclusions given the data. But many people I talked with understand these shootouts as hard facts, they assume language X is always better than language Y and don't take into account for example that they are developing for a Sparc cluster while using benchmarks for Intel/AMD. So when you talk with those people, point them to examples in the benchmarks game that contradict their simplistic understanding. OK, so I would say I don't really have any problems with the shootout but with the perception of these shootouts by many people. And that's why I dislike these shootouts in general. You seem to be arguing that those people would have a more accurate understanding of performance if they had less data! :-) Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Lisp time
--- Stefan Nobis [EMAIL PROTECTED] wrote: Isaac Gouy [EMAIL PROTECTED] writes: - are you thinking of specific methodological objections? Yes, quite some methodological objections. To be fair: I'm no expert in this field and I haven't looked on the site for quite some time. Thank you for being honest. But benchmarks are really hairy, it's really easy to measure much more hardware than compiler aspects, people are very different in proficiency (in one case I heard even about rejection of a faster version of a benchmark in one language -- but I don't remember if this was on alioth or another language comparision compilation of benchmarks). Now you're spreading gossip :-) If there aren't really tight rules and quite some top experts in benchmarking involved, I wouldn't trust any single number... but that's just me and YMMV. I don't think Darren Cook was suggesting that you trust any single number - he linked to pages that compare 18 different measurements. We must make do with the imperfect evidence that we can find, not merely lament its deficiencies. Yes, that's true. But language shootout are much overrated und I doubt that there are any deep insights in there. So yes, I think I'm dismissive. Again, you seem happy to say they are overrated and dismiss them without actually having looked - that is not scientific! I'm sorry but what you've said about the benchmarks game seems to be no more than guesses and assumptions. At least Darren Cook looked. I've said enough. Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Lisp time
http://shootout.alioth.debian.org/ To clarify: I don't really like these non-scientific benchmarks (in many cases I assume no one or only really few people (not including me) really understand what each micro-benchmark is really measuring). I posted the link to the Shoot-out site as it seemed like a fair attempt at being scientific and objective; the OS is constant, they seem to offer benchmarks on 4 different hardware platforms, and the code being used is available for viewing and (as far as I can tell) anyone can post a better version if they think they can do it better. It'd be nice if someone added an alpha-beta tree searcher algorithm, and a zobrist hashing algorithm; then we'd have a much better idea of how language speed affects typical game programming tasks. Any students here with time for that? Darren ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Lisp time
the OS is constant, they seem to offer benchmarks on 4 different hardware platforms Sorry for the noise. I mis-read the top page: they use two platforms, Gentoo on Pentium 4, and Debian on AMD Sempron. (They are very roughly the same, but java6-server stands out as being considerably quicker on Gentoo/Pentium4). Darren ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Lisp time
Don Dailey wrote: By the way, I am no fan of C. I don't like C and have tried some of the languages on your list of languages that are supposedly faster than C. I think you must be getting your information from the web pages for those languages. As a general rule any reasonably fast language is going to claim to be faster than C but shame on you if you believe it. In theory all languages are equal. They can all be transformed to optimized machine code. I am not talking about the theoretical, I'm talking about the reality.And the reality is that right now C is the choice, whether I like it or not I accept it and hope something better will come along. You are right, but there are some cases where alternatives may make sense. For instance, look at the paper Ian Osgood linked to: They used Haskell to spit out highly optimized code for Monte Carlo-simulations. There is also FFTW, which makes very fast FFT code with the help of OCaml. Code generation is one area where using another language might be considered. It doesn't have to be a functional one, or even C: I know of a cryptographic algorithm (Serpent) that has an implementation based on Perl-generated Ada code. Prototyping may also be an idea. Especially if one is experimenting with novel approaches, wouldn't it make sense to make a prototype in Haskell, for instance? Then you may reimplement it in C, very carefully, comparing outputs regularly to check for the playing strength-killing bugs Chess programmers always talk about... Occasionally there may be some language feature that makes up for the performance cost. Like the distributed nature of Erlang, or the software transactional memory libraries that GHC Haskell come with. If you believe the hype, STM scales much better than locking-based shared memory. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Lisp time
Yes, I agree with all your points. FFTW works by building test cases and testing them on the specific processor it runs on. In other words, under program control, many versions are produced just to see which one actually runs fastest.I know the inventer of FFTW (Mateo Frigo of MIT) who also contributed a little bit to my chess program.The code is produced in scheme or lisp but it's produced FOR C. This may not be the case any more, I haven't kept up with FFTW, but I can imagine the same concept being applied with other languages. Mateo was interested in my move generator for chess. It was super fast because I was able to eliminate most of the branching and it was based on code that produced code which caught his interest. Although I didn't use Mateo's technology, we talked about it. It's my dream that something much better will replace C and I'm hopeful that this day will come.I think it will be something like C but much better. I call it a better C, but that doesn't mean it has to look like C, I just hope that it replaces C.To replace C it has to be more than just fast like C, it has to give you pretty much complete control over your code. It's more fun and productive (in the code writing sense) to program in a much higher level language but there are conflicting goals. It's hard to be both a high level and low level language.A true successor to C will probably still be a relatively low level language.My bet is currently on D, but it's too early to be able to predict. - Don Harald Korneliussen wrote: Don Dailey wrote: By the way, I am no fan of C. I don't like C and have tried some of the languages on your list of languages that are supposedly faster than C. I think you must be getting your information from the web pages for those languages. As a general rule any reasonably fast language is going to claim to be faster than C but shame on you if you believe it. In theory all languages are equal. They can all be transformed to optimized machine code. I am not talking about the theoretical, I'm talking about the reality.And the reality is that right now C is the choice, whether I like it or not I accept it and hope something better will come along. You are right, but there are some cases where alternatives may make sense. For instance, look at the paper Ian Osgood linked to: They used Haskell to spit out highly optimized code for Monte Carlo-simulations. There is also FFTW, which makes very fast FFT code with the help of OCaml. Code generation is one area where using another language might be considered. It doesn't have to be a functional one, or even C: I know of a cryptographic algorithm (Serpent) that has an implementation based on Perl-generated Ada code. Prototyping may also be an idea. Especially if one is experimenting with novel approaches, wouldn't it make sense to make a prototype in Haskell, for instance? Then you may reimplement it in C, very carefully, comparing outputs regularly to check for the playing strength-killing bugs Chess programmers always talk about... Occasionally there may be some language feature that makes up for the performance cost. Like the distributed nature of Erlang, or the software transactional memory libraries that GHC Haskell come with. If you believe the hype, STM scales much better than locking-based shared memory. ___ 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/
Re: [computer-go] Lisp time
Hi, It seems to me like in some ways Scheme is less feature bloated than common lisp. in my DOS version of AUGOS, I embedded a small Lisp interpreter (Inflisp) into the Pascal code. The Lisp files, which make up the inference engine, are included in the runtime version downloadable from my web page. Currently I'm writing Augos 7 in C#. This language has many of the advantages of Lisp, for example polymorphy and garbage collection, so Lisp isn't needed any more. For Delphi programmers, I made the sourcecode of Inflisp available at http://www.augos.com/software/inflisp.html Regards, Joachim _ In 5 Schritten zur eigenen Homepage. Jetzt Domain sichern und gestalten! Nur 3,99 EUR/Monat! http://www.maildomain.web.de/?mc=021114 ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Lisp time
On Dec 12, 2007, at 10:09 , Nick Apperson wrote: I've been (and still am) a die hard supporter of C++, but since I program in C++ for work (we develop gamelike software) I get tired of C++ day in and out. I'd also like to push myself to learn some new things. Lisp seems to me like a language I could really come to respect. I run linux (no windows, period) and I am comfortable with command- line if I need to be. Anyway, I'm trying to figure out what the best way would be to learn lisp so that I can begin working on a computer go program in it. I can't even figure out what the right dielect would be for computer go. Any of you out there using lisp want to maybe point me in the right direction for how to learn this language as it applies to writing a go program? Thanks. 1. You go with Common Lisp In this case I'd prefer SBCL as an implementation (we recently had a posting on this list comparing speeds of various Lisps, I think). And then there's of course now way around Emacs! Especially as there's SLIME [1] which is an excellent IDE (console, debugger, documentation, ...) 2. You go with Scheme I don't know much about Scheme, but there are some nice Scheme implementations out there. PLT Scheme has a nice IDE. Gambit Scheme and Chicken Scheme are supposed to be fast (they compile to C). [1] http://common-lisp.net/project/slime/ -- Urban Hafner Ziegelgasse 10 69117 Heidelberg Germany http://bettong.net ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Lisp time
I've looked into this a bit. My preference would be scheme and it's my understanding that it may be a bit more efficient. - Don Urban Hafner wrote: On Dec 12, 2007, at 10:09 , Nick Apperson wrote: I've been (and still am) a die hard supporter of C++, but since I program in C++ for work (we develop gamelike software) I get tired of C++ day in and out. I'd also like to push myself to learn some new things. Lisp seems to me like a language I could really come to respect. I run linux (no windows, period) and I am comfortable with command-line if I need to be. Anyway, I'm trying to figure out what the best way would be to learn lisp so that I can begin working on a computer go program in it. I can't even figure out what the right dielect would be for computer go. Any of you out there using lisp want to maybe point me in the right direction for how to learn this language as it applies to writing a go program? Thanks. 1. You go with Common Lisp In this case I'd prefer SBCL as an implementation (we recently had a posting on this list comparing speeds of various Lisps, I think). And then there's of course now way around Emacs! Especially as there's SLIME [1] which is an excellent IDE (console, debugger, documentation, ...) 2. You go with Scheme I don't know much about Scheme, but there are some nice Scheme implementations out there. PLT Scheme has a nice IDE. Gambit Scheme and Chicken Scheme are supposed to be fast (they compile to C). [1] http://common-lisp.net/project/slime/ --Urban Hafner Ziegelgasse 10 69117 Heidelberg Germany http://bettong.net ___ 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/
Re: [computer-go] Lisp time
I've not used scheme recently, but I certainly recall it fondly. When I we were taught it, the language definition was famously shorter than the index to the definition of the Common LISP. cheers stuart On 12/12/2007, Peter Drake [EMAIL PROTECTED] wrote: Chez Scheme is a good choice. For a book, you want Dybvig's The Scheme Programming Language; it's available in dead-tree form or (free) on-line: http://www.scheme.com/tspl3/ Peter Drake http://www.lclark.edu/~drake/ On Dec 12, 2007, at 1:09 AM, Nick Apperson wrote: I've been (and still am) a die hard supporter of C++, but since I program in C++ for work (we develop gamelike software) I get tired of C++ day in and out. I'd also like to push myself to learn some new things. Lisp seems to me like a language I could really come to respect. I run linux (no windows, period) and I am comfortable with command-line if I need to be. Anyway, I'm trying to figure out what the best way would be to learn lisp so that I can begin working on a computer go program in it. I can't even figure out what the right dielect would be for computer go. Any of you out there using lisp want to maybe point me in the right direction for how to learn this language as it applies to writing a go program? Thanks. - Nick ___ 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/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Lisp time
Any of those with recent Lisp experience have any opinions about multicore capabilities? What I've googled so far looks a bit rudimentary - mostly based on unix fork semantics. I'm looking for something much lighter-weight, Erlang-style, which could support thousands of cheap concurrent threads. In Erlang, the cost of such threads is comparable to the cost of a function call. Terry McIntyre [EMAIL PROTECTED] They mean to govern well; but they mean to govern. They promise to be kind masters; but they mean to be masters. -- Daniel Webster - Original Message From: Nick Apperson [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Wednesday, December 12, 2007 5:09:32 PM Subject: [computer-go] Lisp time I've been (and still am) a die hard supporter of C++, but since I program in C++ for work (we develop gamelike software) I get tired of C++ day in and out. I'd also like to push myself to learn some new things. Lisp seems to me like a language I could really come to respect. I run linux (no windows, period) and I am comfortable with command-line if I need to be. Anyway, I'm trying to figure out what the best way would be to learn lisp so that I can begin working on a computer go program in it. I can't even figure out what the right dielect would be for computer go. Any of you out there using lisp want to maybe point me in the right direction for how to learn this language as it applies to writing a go program? Thanks. - Nick Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Lisp time
I saw this on the Gambit-C web page: With appropriate declarations in the source code the executable programs generated by the compiler run roughly as fast as equivalent C programs. This is another way of saying it run pretty fast but not as fast as C. - Don Urban Hafner wrote: On Dec 12, 2007, at 20:28 , terry mcintyre wrote: Any of those with recent Lisp experience have any opinions about multicore capabilities? What I've googled so far looks a bit rudimentary - mostly based on unix fork semantics. I'm looking for something much lighter-weight, Erlang-style, which could support thousands of cheap concurrent threads. In Erlang, the cost of such threads is comparable to the cost of a function call. There's Termite [1], it's based on Gambit-C Scheme [2] and implements Erlang style concurrency and distributed programming. AFAIK, Gambit-C is also one of the faster Schemes. Or you use Erlang as Vlad suggested. I've started something like this and I'm using libEGO for the move generation. You can have a look at the code but be aware that it doesn't do much of interest right now (just random playouts) and I'm also an Erlang newbie. Anyway here's the code: http://darcs.bettong.net/darcsweb.cgi?r=erlygo;a=summary Urban [1] http://toute.ca/ [2] http://www.iro.umontreal.ca/~gambit/ ___ 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/
Re: [computer-go] Lisp time
On Dec 12, 2007 7:28 PM, terry mcintyre [EMAIL PROTECTED] wrote: What I've googled so far looks a bit rudimentary - mostly based on unix fork semantics. I'm looking for something much lighter-weight, Erlang-style, which could support thousands of cheap concurrent threads. In Erlang, the cost of such threads is comparable to the cost of a function call. Why not go for Erlang, then? :-) There's people talking about starting using a lispy syntax for erlang (of course that won't make it lisp) regards, Vlad ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Lisp time
terry mcintyre [EMAIL PROTECTED] writes: Any of those with recent Lisp experience have any opinions about multicore capabilities? Multithreading is not available in ANSI CL, but most implementations support multithreading in some ways. AFAIK SBCL, Corman Lisp, OpenMCL and some more have true kernel level multithreading without internal locks. What I've googled so far looks a bit rudimentary - mostly based on unix fork semantics. I'm looking for something much lighter-weight, Erlang-style, which could support thousands of cheap concurrent Hmmm... it surely depends on your OS, but nevertheless maybe this is interesting for you: http://common-lisp.net/project/erlisp/ -- Until the next mail..., Stefan. pgppHGtX20Wa6.pgp Description: PGP signature ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Lisp time
On Dec 12, 2007, at 20:28 , terry mcintyre wrote: Any of those with recent Lisp experience have any opinions about multicore capabilities? What I've googled so far looks a bit rudimentary - mostly based on unix fork semantics. I'm looking for something much lighter-weight, Erlang-style, which could support thousands of cheap concurrent threads. In Erlang, the cost of such threads is comparable to the cost of a function call. There's Termite [1], it's based on Gambit-C Scheme [2] and implements Erlang style concurrency and distributed programming. AFAIK, Gambit-C is also one of the faster Schemes. Or you use Erlang as Vlad suggested. I've started something like this and I'm using libEGO for the move generation. You can have a look at the code but be aware that it doesn't do much of interest right now (just random playouts) and I'm also an Erlang newbie. Anyway here's the code: http://darcs.bettong.net/darcsweb.cgi?r=erlygo;a=summary Urban [1] http://toute.ca/ [2] http://www.iro.umontreal.ca/~gambit/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Lisp time
From: Stefan Nobis [EMAIL PROTECTED] terry mcintyre [EMAIL PROTECTED] writes: Any of those with recent Lisp experience have any opinions about multicore capabilities? Multithreading is not available in ANSI CL, but most implementations support multithreading in some ways. AFAIK SBCL, Corman Lisp, OpenMCL and some more have true kernel level multithreading without internal locks. Thanks for the info! What I've googled so far looks a bit rudimentary - mostly based on unix fork semantics. I'm looking for something much lighter-weight, Erlang-style, which could support thousands of cheap concurrent Hmmm... it surely depends on your OS, but nevertheless maybe this is interesting for you: http://common-lisp.net/project/erlisp/ That does look interesting -- but the last post to the erlisp-devel mailing list was in 2005, if we don't count the single spam post in 2006. It's an extremely low-traffic list ;) Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Lisp time
Because I am just starting with Lisp, I find this an easy place to start: http://gigamonkeys.com/book/index.html In the intro is the line: For example, one vacation, having a week or so to hack Lisp, I decided to try writing a version of a program--a system for breeding genetic algorithms to play the game of Go--that I had written early in my career as a Java programmer. From this set of pages, here is a link to an array of Lisp choices: http://gigamonkeys.com/book/lispbox/ Cheers, David On 12, Dec 2007, at 8:34 AM, David Doshay wrote: I am presently engaged in the same search, although I run on Macs and am willing to accept either a GUI or a command-line environment. GUI debuggers can be handy. Cheers, David On 12, Dec 2007, at 7:09 PM, Nick Apperson wrote: I've been (and still am) a die hard supporter of C++, but since I program in C++ for work (we develop gamelike software) I get tired of C++ day in and out. I'd also like to push myself to learn some new things. Lisp seems to me like a language I could really come to respect. I run linux (no windows, period) and I am comfortable with command- line if I need to be. Anyway, I'm trying to figure out what the best way would be to learn lisp so that I can begin working on a computer go program in it. I can't even figure out what the right dielect would be for computer go. Any of you out there using lisp want to maybe point me in the right direction for how to learn this language as it applies to writing a go program? Thanks. - Nick ___ 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/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
