Author: Robert Hyatt
Date: 11:38:44 02/16/04
Go up one level in this thread
On February 16, 2004 at 14:25:10, Tord Romstad wrote: >On February 16, 2004 at 14:03:11, Robert Hyatt wrote: > >>Please re-read my statement. Look at the date. Then re-read yours. >> >>My statement was written in 1997. In general Lisp _was_ interpreted. > >No, it wasn't. Lisp has been a compiled language for *decades*. If you >look at the ANSI Common Lisp standard (from 1991, if I recall correctly), >you will see that the standard even *requires* a compiler. There is >one implementation (CLISP) which compiles only to bytecode, all other >major Lisp implementations have compiled to machine code since a very >long time. > >>Of >>course, so was BASIC. Yet there were basic compilers as well. My primary point >>was speed. Lisp is slow. It always was slow. It always will be slow. > >It *isn't* necessarily slow. I have even provided one data point (from >1999, just two years after your statement was written) to illustrate that >Lisp in practice often enables you to write *faster* programs in *less* >time compared to C/C++. Personally, I would take _any_ challenge to compete with a lisp program, when the goal is performance. Granted, high-level languages may reduce the _development_ time. All the previous languages I have mentioned come to mind, from Prolog, to APL, to Snobol. But when execution speed is the issue, I'll take C _every_ time, and if I were unable to beat a lisp program at speed, for the same functionality, I'd probably turn in my coding pad. :) Just as surely as I would take assembly over C if speed were the ultimate goal, no matter how good the C optimizer is. A bad programmer can write bad C code. A programmer that is not familiar with a computer (take a Cray) will probably get beaten by the optimizer. But for a human that knows the architecture, I'll take the lowest-level language every time, when raw NPS or whatever is the goal. > >For complicated programs, it sometimes requires somewhat more expertise >to write fast code in Lisp compared to C. You will also need some >familarity with the internals of your Lisp implementation. > >I know what I am talking about -- I am not making all of this up. I >have been working as a full-time Lisp programmer for almost three years, >and I have used Lisp extensively before and after that time as well >(mostly for mathematical tasks). In most cases, I find it very hard >to write a C program which performs as well as my Lisp solution to the >same problem. Perhaps that says more about your C programming than your Lisp programming. I've never seen anyone claim that a high-level language produces faster executables than low-level languages. The normal claim is "reduced development time" at the expense of "program performance". Claiming the opposite boggles my imagination. IE do you also believe that a good LISP programmer can beat a good assembly programmer, since he can beat a good C programmer? Not on my watch... > >To a certain extent, the explanation of this is of course that I am >a much better Lisp programmer than C programmer. But I am not a >complete idiot in C either. After all, my chess engine, written in C, >is stronger than most amateur engines. Why not "my chess engine, written in lisp?" ??? > >>That is why there has been no successful chess engine based on LISP yet. > >There hasn't been any attempt to write a conventional chess engine in >Lisp yet. But I know that my engine would have been no weaker if I had >implemented it in CMUCL instead of using gcc. My reason to use C rather >than Lisp is not efficiency, but portability. > >Tord There have been Lisp chess programs in the past. I'm not even sure that Steven didn't write one a long while back, although I am thinking of "AI Chess" and he might have used something else. There is a _reason_ you don't see them in mainstream competition however. That reason is performance, not programming ease/difficulty, etc...
This page took 0.03 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.