Author: Steven Edwards
Date: 03:34:56 02/18/04
Go up one level in this thread
On February 18, 2004 at 05:21:33, Tord Romstad wrote: >On February 17, 2004 at 19:33:52, Vincent Diepeveen wrote: > >>Let's start the functional programming subject. > >Why? Lisp is not a functional programming language, although it allows >you to write programs in a functional style if you want. Functional >programming is not the only, nor even the most common style of programming >in Common Lisp. Generally true. Functional programming (as opposed to imperative programming) certainly has some advantages like easier specification and verification. But these are not as important as might be indicated by the fervor of their advocates (nearly all of whom first learned about Lisp directly or indirectly from the MIT Scheme guys). Then again, I have my own fervor about avoiding C/C++ goto/continue/non-casebody break (and their other language equivalents). >Concerning your problems with the syntax: > >The syntax is fully programmable. Common Lisp readtables are >first-class objects, and can be copied, manipulated and hacked any >way you want. Common Lisp is a language construction kit just as >much as a language. The reason why the default syntax looks the >way it is is that keeping the base syntax as simple and fluid as >possible makes it easier to build new languages on top of it. It >is easy (trivial, in fact) for a Lisp program to write Lisp code, >precisely because of the syntax. While the Common Lisp read tables are programmable, this feature is not used much outside of the topic of bootstrapping other languages. Reprogramming the read tables is akin to writing a boatload of C preprocessor macros to make C look like Pascal or some other language. >>((((((((((a b c)(a))))))(((())))))(((()))) >> >>Sentences like above are not so easy to understand. C is way easier. > >But the line of Lisp "code" above doesn't do anything. It isn't code >at all in any meaningful sense of the word. I would even claim that >you would never even see anything like the above line in a Lisp program, >unless it is written by an incompetent Lisper or it is deliberately >obfuscated. Tord is correct, except no Lisp coder could be _that_ incompetent. >>AFAIK only some grey old emacs fans write their stuff in LISP. Vincent, you need to get out more and get to know programmers who are not all members of single narrow domain. >Emacs Lisp is an old, ugly and inefficient Lisp dialect, and doesn't >really belong in this discussion. Emacs Lisp (samples in all the *.el files in the Emacs distribution) is well suited for its purpose. Emacs works remarkably fast considering its power of expressibility and extendibility. It also proves false the hoary old misconception that "Lisp is slow". >>When i define something in LISP there i continuesly make (((()))((())) >>mistakes. Almost all of this goes away after a few days of Lisp programming experience. >I suppose it happens that I misplace a paren too when writing Lisp, but >it happens no more often than that I forget a semicolon when writing C. >And when I do misplace a paren, at least the error is easy to fix: I >just press C-M-q, and it is immediately obvious exactly where the error >is. Quite true. And unlike C/C++, Lisp always has an interpreter present to quickly detect misplaced (but syntactically correct) parentheses. >But of course, you need a Lisp-aware editor in order to write and edit >Lisp code efficiently. Not really true. Yes, Emacs works very well here, but even the simple auto indentation and parentheses aware features of Apple's Xcode toolkit editor suffice for my Lisp coding with Symbolic.
This page took 0.01 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.