Author: Christophe Theron
Date: 22:06:46 02/23/04
Go up one level in this thread
On February 23, 2004 at 15:03:03, Steven Edwards wrote:
>On February 23, 2004 at 13:52:47, Christophe Theron wrote:
>>On February 23, 2004 at 12:30:47, Steven Edwards wrote:
>
>>From what I see, LISP has a basic "(operator arg arg arg...)" structure (correct
>>me if I'm wrong, the last time I looked at LISP was 15 or 20 years ago).
>
>With the standard readtables in use, you are correct.
>
>>Just a general comment: I find it slightly harder to read than C for example,
>>but naturally I'm very used to reading C so I would probably adapt to LISP,
>>eventually.
>
>I switch between C++ and Lisp, as is rather necessary because of the nature of
>this project, without difficulty. On the other hand, I will never again do any
>regular C coding givun tahht C++ is available.
>
>>But there is something that I find very inelegant: if one is ready to give up on
>>the more standard "operator(arg,arg...)" or "arg1 operator arg2" (like in
>>"a+b"), then it is possible to do it without the parenthesis!
>>
>>Frankly, all thoses parenthesis in your example are absolutely impossible to
>>manage for a normal human. So you had to make the structure obvious by using
>>identation.
>
>Having a decent editor helps a lot. I dont think that experienced Lispers have
>much problem with parentheses; the common errors seem to be with getting the
>right number of evaluations of an expression and also with managing scope
>visibility issues.
>
>>Then these parenthesis appear to be redundant with identation. The identation is
>>there for the human, the parenthesis are there for the computer. Ugly.
>
>After a sufficient amount of Lisp coding, the mind gets better at perceiving
>larger chunks of Lisp, much like reading natural language a whole phrase or
>sentence at a time without consciously perceiving each letter and punctuation
>mark.
>
>>Now how can you do it without the parenthesis?
>>
>>By writing it in Forth!
>>
>>I find Forth to be one of the most elegant language that has ever been designed.
>>It is fast, efficient, and not harder to read than LISP (and because you do not
>>have to insert the parenthesis I would dare to say that it is easier to write
>>and more readable than LISP).
>>
>>You will not use basic "(operator arg arg)" structures, you will use "arg arg
>>operator" instead. Same thing, with the order reversed, and without any
>>parenthesis!
>>
>>So to answer your question: yes I find LISP hard to read, and if I was ready to
>>use a different language I would go to Forth instead of LISP.
>
>Having had to debug the output of PostScript generators, I am well familiar with
>the idea of a Polish Notation programming language. Now, if I had to fit a
>simple application (like telescope pointing control, an early Forth usage) on a
>cheap, low capacity CPU, then I'd consider Forth. But not otherwise.
I find Forth to be extremely elegant, because it is based on a very small number
of concepts. Its syntax is minimalist, almost non-existent. It can be learnt
very quickly, can be implemented (and has probably been implemented) on every
computer out there, and it is even possible to write processors that interpret
Forth directly (Chuck Moore has been working on a clockless one: it computes as
fast as it can, without a clock!).
Its only drawback to me is that it is not as easy to read as other languages, at
least in the begining.
However I must admit that I have not written enough Forth code. I do not know
how it "feels" to program in that language every day.
Maybe it's not that cool, but it's very tempting. The color version seems even
more interesting.
Christophe
>>>3. The above code, like all of ChessLisp, is typesafe. This means that a
>>>function that expects a color checks for a color value, one that expects a
>>>position symbol checks for a position symbol, etc.
>>
>>While this is generally considered as a good thing, I think that type checking
>>has been mostly been overevaluated.
>
>It easily pays for itself during debugging.
>
>>Type checking won't write correct programs for you. Writing correct programs
>>comes from an attitude of being extremely careful and reading your own code
>>several times before trying it.
>
>Typesafety helps mostly in the detection of typographical errors. It is an
>overall time savings to have the interpreter assist. It's like having a spell
>checker.
>
>>>4. Further work on KBNK will help with the design and implementation of the
>>>pattern recognition and planning facilities.
>>
>>Is it supposed to be an argument in favor of LISP? This bit of code could have
>>been written in any language with the same efficiency...
>
>No, it is supposed to be an exaple of endgame class recognition in ChessLisp.
>There are many more recognizers of all varieties that still need to be written.
>
>>If it is supposed to be an argument in favor of pattern recognition, then Chess
>>Tiger must be based on pattern recognition, because I must have an almost
>>identical bit of code somewhere! :)
>
>Nope, the pattern matching stuff is still to come.
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.