- PaulGraham (a big Lisp advocate) on it's history and what made it different : http://paulgraham.com/icad.html
NewLisp is Lisp for CGI scripting etc.
Must watch this : http://swiss.csail.mit.edu/classes/6.001/abelson-sussman-lectures/
What is "code-is-data"?
Most programming languages are stored as text. To operate on code, then, means you'll need to parse that text. Because characters don't correspond to the meanings. (Just like I'm not thinking in terms of letters right now; rather about words, sentences, etc.)
If you want to operate on code, it is best stored in a more convenient data structure.
That is a large point of Lisp, that code is stored in useful data structures. When Lisp was invented, OOP wasn't known. So one data structure used is the list. (Arrays, OOP objects, etc. could have been used, but lists were.) There are other data structures; for example, symbols, numbers, strings, characters, etc.
So this is a program:
And so is this:
(dog 42 "This is a text string!")
The program 42 merely results in 42. The last one is a list holding three things: the symbol dog, the number 42, and the string "This is a text string!". If it were executed as code, it would treat dog as an operator, to operate on the other two.
So Lisp is not about lists. It just happened to be one of the datastructures used in storing code, nothing more. But one that people notice, because those parens stick out.
What is the link to functional programming?
Lisp is not just about functional programming. It simply was perhaps the first programming tool which supported strong, useful functions. At some point, people built a religion around functions.
In fact, the old meaning of "recursion" was simply one function calling another. Nothing more. Today it means a function calling itself at some point.
In Lisp, you can store functions in variables, and there are a couple more useful features. But things which are part of a good meal may become unhealthy, if you eat it exclusively all the time.
In particular, those who teach Scheme frequently push functional programming. Of course, it is good to research it in a sophisticated way, but the temptation to hype it dishonestly is strong -- just like OOP.
At the 2004 ECOOP conference, a quick poll showed that Lisp attendees used loop the most -- loop is like every for(;;) loop in every language rolled up into one. So functional programming isn't that dominant. But you still see it often, even mixed in with other paradigms like iteration.
-- John Gabbour
This is interesting. If I read you correctly you're saying that the "program is data" aspect of Lisp is more important and fundamental than FunctionalProgramming purism? And that many Lisp hackers are happy to use imperative styles. (I was reading my book on EmacsLisp last night and I was quite surprised to discover the "while" and "progn" operators :-) And at the same time, the lists aren't very important at all. Could have been any suitable data-structure which could also hold code. Although it's hard to think of anything else quite so flexible and suitable for holding code.
Lisp is a multiparadigm tool. So, the specific situation facing you pretty much determines what its most important feature is. (In many languages, paradigms announce their arrival like a sitcom character, pausing for applause and dominating the scene. They don't work as an ensemble, where they would simply pick up roles when needed.)
This often isn't clear to newcomers, because vocal users tend to project their personal beliefs heavily. Just as representatives of Earth would offer radically different perspectives to aliens. For example, Paul Graham dislikes OOP and iteration. So he never talks about it. But he seems to like functional programming, lists and macros, giving his audience the impression of that Common Lisp bias.
So you don't need to understand it very intellectually, unless you enjoy that. Program-is-data just lets you operate on code with the same muscles trained for data-handling. There are other things within Lisp that people don't mention, and are potentially more interesting. My operational definition of Lisp is of a system which invites you in. With reasonable defaults, in case you don't want to come deeply in.
You're right in that lists are very flexible and yet simple. And datastructures are so low-level that it's probably the best choice to take such a light cord and run with it. But I sometimes want data "associated" with code without having to look at it, like line numbers. If I'm writing a library which should give good error messages, I might want to emit line numbers. I think OOP may have a role here, so most code can be like it is today (lists, numbers, etc.), but I can also attach extra data onto a piece of code.
Type information (like x is an integer) could be another useful thing I don't want cluttering up my screen. Maybe my IDE can show x in a different color, and I can "rotate it in the 3rd dimension" to see the type info.
But maybe that's head-in-the-clouds dreaming, one of those things I wouldn't actually use. It's all up to experiment.
Lisp macros aren't defined that often. I'd guess the common usage is of other people's macros, which were debugged over decades. (Such as loop.)
Lisp macros allow community extensions to the tool. Maybe a more interesting, general point than simply claiming code-is-data as a wizzy feature.
RubyLanguage as an acceptable Lisp : http://www.randomhacks.net/articles/2005/12/03/why-ruby-is-an-acceptable-lisp
Lisp is not an acceptable Lisp : http://steve-yegge.blogspot.com/2006/04/lisp-is-not-acceptable-lisp.html