Author: Vincent Diepeveen
Date: 04:58:10 02/18/04
Go up one level in this thread
On February 18, 2004 at 06:34:56, Steven Edwards wrote: >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. You're talking to yourself. >>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". $ emacs diep.ini & EMACS is dead slow. It takes like 20 seconds to start it the first time. That's sick long for just editting a simple textfile. Emacs is the only editor i use under linux because i know how to modify it's lisp (when i have the time to remember that and do it) and because i remember a lot of its cryptic commands. Yet it is not so fun to edit source code with it. It works a lot slower there and it is in fact dead slow without redefining function keys in LISP. The only reason i work under windows at the moment is because of superior editors under windows. >>>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 guess if you live in hell you will get used to it too. >>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. All editors have that for C. Additionally i have great colorization of my source code in C because there is many great editors for it. LISP is not supported in any of these editors. Note all these features are needed for beginning programmers. I nowadays write a lot of code which only needs to get compiled only once. Zero errors. >>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 Emacs is a very slow development environment where still the lemma applies that programmers on average program 0.5 source code lines an hour with. >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.