Author: Vincent Diepeveen
Date: 01:27:13 02/18/04
Go up one level in this thread
On February 17, 2004 at 23:12:08, Robert Hyatt wrote:
>On February 17, 2004 at 19:33:52, Vincent Diepeveen wrote:
>
>>On February 17, 2004 at 06:41:11, Tord Romstad wrote:
>>
>>>On February 16, 2004 at 14:38:44, Robert Hyatt wrote:
>>>
>>>>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.
>>>
>>>The key point is the "knows the architecture" part. Just like an assembly
>>>language program doesn't automatically run faster than a C program just
>>>because it is written in assembly language, a C program doesn't automatically
>>>run faster than a Lisp program just because it is written in C. In both
>>>cases, you need some in-depth knowledge of the computer hardware to take
>>>advantage of the low-level features of C or assembly language. In both
>>>cases, the performance gain given by the lowest-level language isn't
>>>extremely big. Given optimizing compilers of the same quality, the
>>>performance difference between assembly language and C is probably
>>>comparable to the difference between C and Lisp.
>>
>>Though i love Hyatt crawling over the floor, i have to admit that in this case
>>he must be crawling laughing for your idiocy here.
>
>Vincent, you won't _ever_ find me "crawling on the floor." Because I don't
>engage in the behavior that leads to that (heavy drinking). Perhaps that does
>explain many of your rather insane statements here, however, as they often do
>sound as if they come from someone dead drunk.
Don't make yourself crawl too much. I do not drink alcohol at all by the way.
Note the photo at your homepage indicated an old man dissappointed in life.
>
>
>
>>
>>Let's start the functional programming subject.
>>
>>I wrote a checkersprogram in a functional language. It was called gofer
>>(developed at university amsterdam). Deliberately i didn't use Haskell features
>>because haskell is in fact imperative and that would defeat the goal.
>>
>>The checkers program using lazy evaluation and such high level language stuff,
>>was searching at 2 nodes a second.
>>
>
>
>That does _not_ mean someone else can't do it better. Again, for the record,
>just because _you_ can't do it does _not_ mean it can't be done. On the
>contrary, it just means you can't do it yourself... and nothing more.
Ah i didn't tell the good part of course.
It has been optimized for a year by someone trying to get his doctor title under
professor Swierstra (functional programming group). He managed to speed it up a
factor 2 after which it was a factor 50 slower when compiled :)
>>It took me a week or 2 to make and optimize the gofer program.
>Must have been some optimization job...
>
>>
>>Then i converted that by hand into a C program. That took 1 day and it was
>>10000-20000 times faster. Of course interpreted.
>>
>>When compiled the C program was factor 50-100 faster.
>>
>>Functional programming languages would be great to parse anything and easy to
>>use.
>
>
>There are plenty of reasons for functional language development. I could point
>you to a group at Lawrence Livermore National Laboratory in the US as one place
>where this goes on. There are many others. With _that_ kind of brainpower
>using it, it can't be all bad...
There isn't any reason to write anything in a functional language other than why
people create their own new programming language for such as the simple
programming language that i created. To practice a few things.
>
>
>>
>>Well after writing a checkersprogram i realized at least 2 of its disadvantages.
>>Not only it's dead slow but also you can only make small functions. Have you
>>ever written a serious application in LISP?
>>
>>I doubt it.
>>
>>Really i do.
>>
>>((((((((((a b c)(a))))))(((())))))(((())))
>>
>>Sentences like above are not so easy to understand. C is way easier.
>
>So? Declaring an array of functions that return pointers to functions that
>return pointers to arrays is also very messy-looking in C. Just don't do it.
I know you are completely lacking any knowledge here to be able to judge
anything, but you should like me try to have a look after the program Paradise
from Wilkins. It's a couple of hundreds of pages of LISP code.
Then you'll understand the problem. Until then i'm sure not having any knowledge
on LISP terrain will not stop you.
>
>
>
>>
>>However if you write a chessprogram in LISP you will end up with tens of
>>thousands of lines of the above.
>>
>>In fact i am 100% sure that a C chessprogram is SMALLER than a LISP chess
>>program is, when just looking to the code size.
>>
>>Now we didn't talk about readability. C is easily readable.
>
>It _can_ be easily readable. It can be completely unreadable. It, as always,
>depends on the programmer.
You don't even know the syntax from LISP this is amazing :)
No it is not so easy like in C to write good readable source code.
Jeez i'm really talking to a complete LISP beginner here.
>
>>
>>A huge program when written in LISP will have ten thousand different functions.
>>That really is very bad. Trivially no compiler will be ever capable of
>>optimizing that well.
>>
>>AFAIK only some grey old emacs fans write their stuff in LISP. When i define
>>something in LISP there i continuesly make (((()))((())) mistakes.
>>
>>Defending such a functional dynosaur language as being a good language to
>>program in is against any common sense.
>>
>>Let's summarize the problems of it
>> - too slow
>> - too many functions
>> - difficult to read code thanks to the ((()))(())(()))((
>> - really slow
>> - even slower
>> - dead slow
>> - slow to program complex applications in too by the way
>>
>>
>>>>>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 already conceded that point. If you read my last post again, you
>>>will see that I explicitly state that I am a much better Lisp programmer
>>>than C programmer. You are one of those who have detailed knowledge and
>>>lots of experience with low-level programming and computer hardware,
>>>and you are therefore able to squeeze out more performance from a C or
>>>assembly language program than I would ever manage. Without such
>>>knowledge (which, I think, most of us do not posess), C simply doesn't
>>>offer any significant performance advantage.
>>>
>>>>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...
>>>
>>>There is noone who forces you to use the same language for the whole program,
>>>of course. Performance-critical parts of a Lisp program could be rewritten
>>>in C or assembly language. Mixing Lisp and assembly language tends to be
>>>much easier and more comfortable than mixing C and assembly language, because
>>>of the power of Lisp macros.
>>>
>>>>>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?"
>>>>
>>>>???
>>>
>>>
>>>If you read a few more lines of my post, you would see the answer.
>>>Portability. I want to use the same code on Mac OS X, Linux and
>>>Windows, and I have long-term plans to port my engine to Palm OS.
>>>
>>>>>
>>>>>>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.
>>>
>>>Yes, Steven started on a project called CIL ("Chess In Lisp"). It is not
>>>a complete program. The code which is there is entirely unoptimized and
>>>looks like a complete joke, probably because the project was abandoned
>>>early.
>>>
>>>The only complete Lisp chess engine I have seen is called BCE. This is
>>>terribly weak, but the authors C chess program ("Bace") is not much
>>>better (rated 1319 on Leo's rating list).
>>>
>>>I repeat; there has been no serious effort to make any conventional chess
>>>engine in a modern version of Lisp, and I know that my own engine (currently
>>>rated 2733 in blitz on ICC, on a PIV 2.4 GHz) would perform at most
>>>marginally worse if I rewrote it in Lisp.
>>>
>>>Tord
This page took 0 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.