Practical Common Lisp

Frank Buss writes "Common Lisp is an ANSI standard, which defines a general purpose language and library, and is implemented by free and commercial compilers and IDEs; see *hyper-cliki* for more general information about Common Lisp. The book Practical Common Lisp explains the language with many practical examples and is available in full text online, too." Read on for the rest of Buss' review.

Unlike other good books about Lisp, which are focused on a specific domain, like AI (such as Paradigms of Artificial Intelligence Programming ) or basic computer science (for example Structure and Interpretation of Computer Programs for the Lisp-like language Scheme), this book focuses on solving real-world problems in Common Lisp, like web programming, testing etc., after introducing the language by examples in the first chapters. I started with Lisp half an year ago, and it has helped me a lot in learning it. But even if you already know Lisp, this book may be useful for you, because it has a fresh view on the language and the examples in the later chapters are usable in your day-to-day work as a programmer.

The first chapter tells you something about the author (he was a good Java programmer before starting with Lisp) and the history of Lisp and Lisp dialects like Scheme. The next chapters are a tour through all Lisp features, written in easy-to-understand steps, beginning with the installation of a Lisp system and an introduction to the interactive REPL. You don't need any experience in other languages to understand it.

The general concept throughout is to explain a feature first, then show an example of how to use it, with detailed discussion of what the example does and possible pitfalls. A nice example is the APPEND function, which does not copy the last argument:

The reason most list functions are written functionally is it allows them to return results that share cons cells with their arguments. To take a concrete example, the function APPEND takes any number of list arguments and returns a new list containing the elements of all its arguments. For instance:(append (list 1 2) (list 3 4)) ==> (1 2 3 4)

From a functional point of view, APPEND's job is to return the list (1 2 3 4) without modifying any of the cons cells in the lists (1 2) and (3 4). One obvious way to achieve that goal is to create a completely new list consisting of four new cons cells. However, that's more work than is necessary. Instead, APPEND actually makes only two new cons cells to hold the values 1 and 2, linking them together and pointing the CDR of the second cons cell at the head of the last argument, the list (3 4). It then returns the cons cell containing the 1. None of the original cons cells has been modified, and the result is indeed the list (1 2 3 4). The only wrinkle is that the list returned by APPEND shares some cons cells with the list (3 4). The resulting structure looks like this:

In general, APPEND must copy all but its last argument, but it can always return a result that shares structure with the last argument.

In chapter 9, the first larger practical example is developed, a unit testing framework (like JUnit), which is easy to use and to enhance.

Certain Lisp implementation behaviors can be confusing, such as those for for building pathnames. The pathname concept in Lisp is very abstract, leading to different choices in different implementations. This is no problem if you use only one implementation, but chapter 15 develops a portable pathname library, which works on many implementations. By doing this, it shows you how to write portable Lisp code, using different code for different implementations with reader macros.

After an introduction to the Common Lisp Object System (CLOS) and a few practical FORMAT recipes (the printf for Lisp, but more powerful), chapter 19, "Beyond Exception Handling: Conditions and Restarts", is really useful. The exception handling in Lisp (called "condition system") is more general than other exeption systems: In Lisp you can define restarts where you generate an exception and the exeption handler can call these restarts to continue the program. After reading this chapter, you'll never again want to use the restricted version of Java or C++ exception handling.

Chapters 23 to 31 show real world examples: a spam filter, parsing binary files, an ID3 parser, Web programming with AllegroServe, an MP3 database, a Shoutcast server, an MP3 browser and an HTML generation library with interpreter and compiler. If you ever thought that Lisp is an old language, only used for AI research, these chapters prove you wrong: Especially the binary files parser shows you, how you can extend the language with macros for implementing binary file readers, which looks nearly as clear and compact as the plain text binary file description itself. I'm using some of the ideas for a Macromedia Flash SWF file reader/writer I'm currently writing. Take a look at my Web page for my currently published Lisp projects.

The Web programming chapters demonstrates how to use a dynamic approach for generating web pages. You just start a Web server in your Lisp environment; then you can publish static Web pages or define functions, which are called when the page is requested by a browser. The author demonstrates how to define dynamic pages with formulars in Lisp and Lisp HTML generators.

After reading Practical Common Lisp, you will know most of Common Lisp and how to write real-world programs with it. Some special features, like set-dispatch-macro-character, or using one of the non-standard GUI libraries, are not explained, but it is easy to learn the rest of Common Lisp and to use other Lisp libraries, with the knowledge gained from this book.

---

You can purchase Practical Common Lisp from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page

I'm sorry,

But since we're practicing it, Isn't that supposed to be lithp

Re:I'm sorry,

thtop. that'th a thtupid potht. you thould be athamed.

Things might have been different

It is such a shame that C-based languages took over the computer world in the 1980's. If we had followed the Lisp path instead things might be so much better. C++ with all of the template, RTTI, and STL grunge is such a half-assed imitation of powerful Lisp constructs that have been perfected for 15 years. I won't even go into Java, Python, C#, PHP. What a waste. I suggest you non-Lisp programmers grab a copy of SICP [mit.edu] and start over.

My first exposure to list ( and a mirror of book )

Whenever I think of Lisp, I'm transported back in time to 1975 where I'm trying (unsuccessfully) to learn this as my 2nd programming language after Fortran IV (on a DECsystem-10, no less).

I never revisited Lisp. Perhaps now that I have the book, I'll give it a shot.

You can download a copy here [networkmirror.com] if the main site is too busy.
~

Re:My first exposure to list ( and a mirror of boo

If you find LISP interesting, Haskell might also be of interest.

Recent interest in Haskell has exploded because of the implementation of Pugs [pugscode.org] in GHC. Pugs is a compiler / interpreter prototype for Perl 6, which is also a functional language, borrowing many concepts from LISP and smalltalk (as well as just about every other popular research or practical programming language).

Re:My first exposure to list ( and a mirror of boo

Some of the key differences between Haskell and Lisp are:

• Haskell has a strong typing system, similar to that of ML. Lisp's type system is optional, and while many Lisp implementations can do type inference and checking, it isn't required, nor is it as big a part of the language.
• Haskell is purely functional, and it fakes side-effects with the Monad design pattern. Lisp has side-effects, with all the advantages and disadvantages that entails.
• Haskell uses lazy evaluation. Lisp uses strict evaluation unless you explicitly ask for lazy evaluation.
• Lisp, thanks to all those parentheses, has very powerful macros. I know every Lisp fan says this, but they're really cool. Haskell relies more on higher-order functions and infix syntax for that sort of thing, which isn't as powerful but which you may find to be a decent tradeoff.
• Haskell has significant whitespace, like Python. Lisp doesn't.
• I find that editing Lisp code is easier than editing Haskell code, due to the excellent Lisp editing modes available for various text editors. OTOH, maybe that's partly because haskell-mode for emacs is pretty rough.
• Lisp can generally be made faster than Haskell, which is very nice in bottlenecks. For the rest of the program, though, this isn't so major.

Re:My first exposure to list ( and a mirror of boo

First off, let me say that I'm new to Haskell, and learning it, Python and (as of last night) Fortress at the same time, so I'm far from an expert.

"Lisp can generally be made faster than Haskell"

Certainly, and I'm not saying Haskell makes a good language for day-to-day coding. I'm just saying that it's a good place to learn functional programming.

"Haskell uses lazy evaluation. Lisp uses strict evaluation unless you explicitly ask for lazy evaluation."

For those who do not understand this point, it's worth going into. In C, when you say:

c = foo() + bar();

you call functioan foo and bar, add their results, and store that result in c. In Haskell a similar construct would store in c the information required to call foo and bar at a later time when/if you needed the value of c, but of course, if you just add c to another value, you just create a more complex result, you still don't invoke foo or bar.

This is a very powerful concept, but can also lead to surprising results if you are used to programming in non-lazy languages.

Re:My first exposure to list ( and a mirror of boo

Whenever I think of Lisp, I'm transported back in time to 1975 where I'm trying (unsuccessfully) to learn this as my 2nd programming language after Fortran IV (on a DECsystem-10, no less).

I've heard it said that someone just learning how to program can pick up Lisp in a day. If you happen to already know Fortran, it will take two days.

LISP is amazing.

I took a Programming Languages course up at Michigan Tech a couple years back. We wrote our own interpreter using nothing but Common LISP, and it blew my mind. It got me really interested in programming language design.
However, LISP can also be hard to learn. The function names don't make sense to most people who have been raised on higher-level (1980s+) languages. I mean, 'car' to grab the first element of a list, and 'cdr' to grab all the others? It can get downright confusing sometimes.

Re:LISP is amazing.

I mean, 'car' to grab the first element of a list, and 'cdr' to grab all the others? It can get downright confusing sometimes.

But it leads to hilarious bumper stickers, such as: "My other car is a cdr"

Re:Tcl/Tk RULES!!!

Delayed compilation is a feature!

Which would you rather have, a syntax error where indicating the code is faulty, or a silent semantics error?

Although (ahem) uh, the possibility of the former doesn't preclude the latter, but, uh, please observe the authoratative manner in which I wave my hands!

Re:LISP is amazing.

It's much easier to use than assembly. In assembly language, for example, it would be non-trivial to do something like this:

(remove-if-not #'oddp list-of-numbers)

That returns a list of all odd numbers in a list of numbers. With this sort of a difference in ease of use, why are you comparing Lisp to assembly language? My guess is that you're just talking out your ass.

Re:LISP is amazing.

I love it when people comment on Lisp without learning even most rudimentary aspects of the language. Not to single you out, but it is obvious to when one reads a comment posted by someone who is regurgitating commentary provided elsewhere by other who know nothing about the subject.

I'm not certain what you've learned, but it certainly isn't "a lot". Certainly not about programming language design in general, and Lisp in particular. If you had even taken the time to read about just the history and design of Lisp, which is accessible to even the layman, you'd be able to post a more insightful comment than you just did. Why don't you try that, at minimum, since you are obviously uninterested and/or incapable of learning the technical apsects of the language.

As for Lisp being an experimental language, nothing could be farther than the truth. Lisp is a language that was several decades ahead of its time in design, functionality and capability. Everything else is just now catching up. Evidence all the effort to fold in Lispy features into Python, Perl, Ruby, etc., etc. The thing is, these languages' designers are trying to bolt the features into their language after the fact. While Lisp Just Works.

So, since you raised the topic, what's the answer? What would you have us "move on" to?

Re:engineering tradeoffs

Okay, try to name (or point to an article online that names) something wrong (or suboptimal, etc.) with the Common Lisp implementation of scoping, naming, reflection and code generation. Seriously, I'm really interested. I'm not an expert on Common Lisp myself, and all I'd read suggested that Common Lisp was actually far superior to any other programming language re: reflection and code generation (and I'd never heard of any problems in the way it handles scoping or naming).

CL has some problems with the Meta Object Protocol (MOP), which is used for reflection and to modify the object system. It's not standard, but it's supported by all major Lisp implementations---and they usually have small differences, most prominently what package they put it in. Is it in the MOP package? Or perhaps the SB-PCL package? In order to make portable code that uses the MOP, you need a compatibility layer like Closer [common-lisp.net] or MOPP or CLIM-MOP.

That said, once you have all the compatibility code in place you can do amazing things with the MOP. I co-wrote a graphical object inspector that made heavy use of Lisp's introspection abilities, and Pascal Costanza added Aspect-oriented programming to Common Lisp with AspectL [common-lisp.net].

Re:LISP is amazing.

What does 'contents of decrement address decrement register' mean? Nothing, thats what it means. It doesn't even refer to the way that the old LISP machine hardware worked. Its a false mnemonic.

the mnemonics describe the implementation of cons cells (the basic elements from which lists are constructed, but which also can be used for other purposes). they actually are the IBM 704 assembler instructions to access the componenets of cons cells. Most (all?) lisp implementations provide other mnemonics tailored for the particular datastructures, but Lisp has a tradition of backwards compatibility, so the car and cdr mnmonics were kept in

Besides which, just look at modern functional languages; its obvious that the excessive parenthisation in LISP is totally uneccesary.

the original spec of lisp (the lisp1.5 manual) used both the current syntax and a more algol like syntax, but the first implementation was done in the parenthesized syntax. as one of the texts on the history of lisp explains, the suitability of the s-expression syntax for mcro processing was discovered quite early and convinced practically all lisp users not to bother with a more traditional surface syntax, even though there were a few attempts (one of the first i remember was something called Lisp2 done at Stanford in the early to mid 1960s. it looke very much like algol.

They just couldn't write a parser for shit so they took the old adage "If in doubt, bracket" far too seriously and made it compulsory.

bull.

That's not what car and cdr are for...

That's probably not the right way to think about it. A cons cell is a data structure that holds a pair of items. The first is the car; the second is the cdr. The accessors for those parts of a cons cell also have the names car and cdr.

Linked lists are just one data structure that you can implement with cons cells. You can also implement a stack, queue, binary-tree, association-list, etc...

If your are using "cons cells" in your program, use car and cdr.
If you are using lists that are implemented via cons cells use first and rest.
If you are using a stack use push and pop.
And so on...

In other words:

CL-USER> (car (cons 1 2))
1
CL-USER> (cdr (cons 1 2))
2
CL-USER> (first (list 1 2 3))
1
CL-USER> (rest (list 1 2 3))
(2 3)

Justin Dubs

Re:LISP is amazing.

Ok, first imagine what it would take to add something to a language like Java. Let's take try/catch/finally as an example. You might have some java code that works like:

try {
methodCall();
} catch (Exception e){ //TODO: we'll clean this up later
} finally {
otherMethodCall();
}

Now let's say I wanted something like try/catch only specifically geared toward database transactions. I want it to look like this:

tran { //db operations go here
} rollback { // code handling rollback
} success { // code specific to a successful transaction
}

You just can't do that. Sure you could get similar functionality through the use of try/catch and a bunch of helper functions, but you can't integrate it straight into the language itself. You can only add to the language's library. In LISP, there is no real difference.

I can implement a "tran" macro so I can do things like:

(tran (withdraw 25.00 from-account)
(deposit 25.00 to-account) :rollback #'rollback))

This particular instance is my favorite example. It may not seem like a big deal, but I have hundreds of these things that aren't a big deal in my code. If I think something can be done a better way in the language I can add it.

The tran macro would be expanded during runtime to something that looks more like:

(begin-tran)
(withdraw...)
(deposit...)
(end- tran) or (rollback) depending on what happened.

A more complicated version of this macro could take into account nested versions of itself.

Someone will say that try/catch can be made to accomplish what I want. Yes it can. Those same people won't admit however that Perl can be bent to do what Java does.

There is a lot of writing about how great it is to have macro expansion at runtime. That was always meaningless to me until I latched on to that "tran" example above. All of a sudden I realized I wasn't bound to passing values (or references to values, essentially the same thing) to a function. Now I could pass whole chunks of code around. This struck me as such a right thing to do. I'd always been bugged that all the Java consultants around me were memorizing patterns. If something is a pattern, shouldn't the computer be doing it? LISP told me that yes, the computer should be doing it, not that I should be writing pages of patterned code.

It took me a year of talking to one of the guys I worked with where I explained macros to him. Six months after I left that place we went to lunch and he told me he finally saw the light as he was cutting and pasting some in one of his J2EE programs.

If you've ever been looking at something in the language (not the library) and wished that it worked just like that, only different, that is one case where you use a macro.

This is not a troll, but a query...

Could someone proficient in LISP give me three cogent reasons to learn the language?

Re:This is not a troll, but a query...

1) macros will blow your mind. Read Paul Grahams' 'On Lisp'
2) takes bottom-up programming to the extreme. Really does help, but takes a while to get used to.
3) Much better to develop in...interact with the interpreter, compile individual functions and run them, change variables in a running image...

Re:This is not a troll, but a query...

1) macros will blow your mind. Read Paul Grahams' 'On Lisp'
2) takes bottom-up programming to the extreme. Really does help, but takes a while to get used to.
3) Much better to develop in...interact with the interpreter, compile individual functions and run them, change variables in a running image...

Of course, these things are true of most any functional language. IMHO, LISP is a poor choice as a starter language if you're looking for the above wins. I would start with Haskell or Scheme and move on to LISP once you had your bearings.

Common LISP is a very old language (not as old as LISP, of course), full of the same kinds of pitfalls that any language its age or older shows (e.g. C, FORTRAN, etc). It is best to start with younger languages and work your way back.

Re:This is not a troll, but a query...

Of course, these things are true of most any functional language. IMHO, LISP is a poor choice as a starter language if you're looking for the above wins. I would start with Haskell or Scheme and move on to LISP once you had your bearings.

This is what I did, and it was a mistake for me. Many parts of Lisp are far "newer" than other languages because it is far easier to modernize.

For example, Qi is built on Common Lisp and claims to have "the most powerful type system of any existing functional language." I think it's a fancy academic language, but the win is that you can combine it with the hardened industrial features of Common Lisp.

Re:This is not a troll, but a query...

Really? Which functional language has macros?

Which functional language lets you redefine stuff in a running image?

Haskell might be good for real functional programming, but in Lisp you don't do that much functional programming.

I learnt Scheme first, actually, and I'm not that impressed, just like Haskell didn't impress me that much. Scheme is a stripped down Common Lisp with nicer syntax, a weird macro system, and an emphasis on functional programming.

And I don't see in what way Common Lisp has old warts, compared to FORTRAN or C...

It was standardized in 1984, with an object system. That's not too bad, IMHO, considering that Java is just a worse smalltalk-80 and that other C dialects similarly seems to be stuck with '70s technology, compared to Common Lisp.

Re:This is not a troll, but a query...

If you think that macros in any language are better than the ones in Lisp you are very uninformed... and you clearly never used Lisp. Lisp macros manipulate and transform Lisp expressions. Once you have used them you will be completely amazed at how powerful this is.

As for starting with younger languages... cripes. Common Lisp became an ANSI standard in 1994. It continues to evolve and has two commercial companies behind it, and many open source projects.

Re:This is not a troll, but a query...

1. You can post on slashdot when ever the topic comes up.

2. You can think of yourself as extra cool.

3. It'll get you laid.

Re:This is not a troll, but a query...

"Lisp is worth learning for the profound enlightenment experience you will have when you finally get it; that experience will make you a better programmer for the rest of your days, even if you never actually use Lisp itself a lot."

- Eric Raymond, "How to Become a Hacker"

Re:This is not a troll, but a query...

There is really only one thing you need to know about lisp- Lisp essentially has NO SYNTAX. What this means is that your program is an abstract syntax tree that goes directly into the compiler.

Compilers in other languages first need to convert the program into an AST before compiling the code. (this is a bit of an oversimplification, but essentially true.) If you want three reasons, I can explain the repercussions of programming directly in an AST:

Elegance: In Lisp, you don't have to worry about idiosyncracies in the head of the language designers like you do in other languages: You don't have to worry about whether AND has precedence over EQUALS (Delphi programmers know this trap) you don't need to worry when a line needs to end in a semicolon, etc. etc.

Macros: By being an AST, Lisp lets you trick the compiler into thinking it sees other code than is actually there. This is COMPLETELY DIFFERENT than so-called "macros" in other languages- In Lisp you can turn your programming language into basically ANY programming language you want, within the language itself. Read Peter's excellent book or check out this site [lisperati.com] for more info.

Productivity: You can program in the purely-functional style that has been shown to increase programmer productivity by having a property called "referential transparency" and having the easily serializable syntax-expression format. Basically, with Lisp you can analyze/manipulate/automate the bejeezus out of your code very easily, under the mantra "code is data, data is code".

That's what I like about Lisp, anyway...

The advantages of functional languages

- C++ is more readable than assembler
- C# and Java are more readable than C++ ...
- At the end of this list are functional programming languages.

If you can read source more easily, then maintainability will be better. Most projects maintain code, they write new code less often.

This article [paulgraham.com] will tell you why you should be interested in functional programming languages (this link is about Lisp). If you're smart and open minded, you will be convinced.

The best functional languages are Haskell [haskell.org] and Erlang [erlang.org] (click "next" at the bottom of the page). But like the review and link indicate, there's actual value to learning Lisp.

However, the book review is much too in-depth and has jargon.

A simpler example: with Java you prevent bugs by static typing variables, example:

int numberOfTries = 3;

If you later try to fill "numberOfTries" with a string, the compiler will warn you of a bug and you'll have prevented it. The Java compiler makes it a rule that you have to give a type to your variable so your code quality will be higher (fewer bugs).

With Haskell, you don't have to type int. Haskell will figure out the type for you, you get the benefit of preventing bugs with the convenience of not having to type variables. There are other good features like that in functional programming languages.

You could say that every language puts restrictions on what the programmer can do. I mean writing the source code is bottlenecked by the rules of the language (every variable should have a type. You can't do this/that etc.) so that the resulting code AUTOMATICALLY has fewer bugs. Well the amount of source "laws" in functional languages is much lower than in C++ and Java. This means that there is less to remember for a programmer and there is less chance for rules to conflict/interact with each other (in Java you can't use certain variable types in static classes = another meta rule to remember).

Besides having less rules to remember and take into consideration. The functional languages have also chosen the best "laws" to follow. I mean that if you follow the source laws of Java, it's still relatively easy to produce buggy programs, with functional languages it's harder to produce implementation bugs (thinking bugs are always possible but that's your problem).

The only problems with functional programming languages is that the rules which govern source code are very good, but also very different from the rules in traditional programming languages. It might seem like thinking upside down/backwards for people already familiar with procedural languages. Another problem is that because of humans sticking to what they know, the libraries of the functional languages aren't as extensive as those of Java for example. This means that you'll have to program more parts of your program yourself instead of just using a ready made library which fits the task. This problem is limited by the fact that you can program 10 times faster than in Java and, as I said, maintenance takes up most of the time anyway.

The reason I chose Erlang is because with functional purely functional programming languages like Erlang, you can automatically multitask your program over several CPU's (or this will take minimal effort). Nice feature to have in the future because every CPU manufacturer is going multi-core chip now. The future is in multiprocessor machines, not higher clockspeeds (unless diamond wafers become viable) (Lisp is not purely functional by the way).

Also, you can easily make a server that never goes down with Erlang because your server is automatically clustered. Just plonk down a couple networked PC's and if one dies, the server cluster will just keep on going (a bit slower) until you replaced the power supply of the broken

Read the rest of this comment...

Re:This is not a troll, but a query...

No, that's not what I'm asking for; although I will admit that I like Ruby's ability to pass a following code block into any function, this is really something completely different. (For non-rubyers: the poster is talking about a facility that's similar to being able to pass an anonymous function as an argument with nice, clean syntax that doesn't get in your way - similar to the way that the perl builtin sort and map functions let you pass in a block)

A macro basically allows you to rewrite code completely, reaching into the bowels (if necessary) to rip out and mangle what needs to be done.

A basic example is the setf macro. This macro is used for basic assignments:

(setf captain "Picard")
(setf answer (+ 23 42))

Except, of course, that the first argument can be more than just a simple symbol:

(setf (aref array 0 10) new-value)
(setf (car mypair) mynewcar)

So far... so what, right? After all, this "fancy" syntax is just equivalent to the java code:

array[0][10] = new_value;
mypair.car = mynewcar;

Okay, but how about this - suppose I define some functions dealing with a simple berkeley-style database. Say, (get-from-db dbref keyvalue) and (set-to-db dbref keyvalue newvalue). Now, if I set things up properly, I can make setf work with these functions too, so that the user can do:

(setf myprevval (get-from-db id key))
; some calculations on the previous value here
; do some other stuff here
; some calculations to get the new value
(setf (get-from-db id key) newvalue)

See how I never explicitly call my database setting function? The last line there never actually calls my get-from-db function - instead, it reaches into the parentheses and rewrites the code so that what happens is a call to set-to-db.

That is, the user never has to know about the set function. Essentially, setf means "here, in the code, where I've said setf, instead go ahead and use whatever the appropriate setter function is for a reference of this type". (when I defined my db functions, I would have to call some macros to tell setf about get-from-db and set-to-db)

Now, for this specific case - creating a unifrom set syntax for any "get"-type function you wish - Ruby has specific explicit syntax support. (just name the "set" method the same as the "get" method but add an "=" to the end of the name) Lisp, however, handles setf through the more general macro mechanism. This means that it can be extended in a bunch of different ways. For example, Lisp defines incf to mean roughly what C's "++" operator does, except again without special language support. (And incf will automaticaly take advantage of the setup I've already done for setf)

In order to do its magic, setf has to be able to access the reference (get-from-db id newval) exactly as I typed it, and has to be able to rip apart and inspect the innards. This is something only a macro can do.

"Practical lisp" is an oxymoron

Sorry, had to be said.

Lisp Scheme

Lisp is essentially the same as scheme. It's the hardest language to write for IMHO just cause it's out of ordinary.

There was a story of a hacker stole one of the A.I code from the government. The code turned out to be the last 100 pages of the program. It was all closing paranthesis. That should sum up how nasty the language is.

Common Lisp and Schem are really different.

Comon Lisp and Scheme are as different as programming languages can be.

Scheme can be said to be ontological attack against Lisp. It looks Lisp but is as far from Lispiness as you can and being still Lisplike.

Schemer: "Buddha is small, clean, and serious."
Lispnik: "Buddha is big, has hairy armpits, and laughs."
-- Nikodemus

Greenspun's Tenth Rule of Programming:
"Any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp."

Common Lisp people seem to behave in a way that is akin to the Borg: they study the various new things that people do with interest and then find that it was eminently doable in Common Lisp all along and that they can use these new techniques if they think they need them.
-- Erik Nagggum

More than anything else, I think it is the ability of Lisp programs to manipulate Lisp expressions that sets Lisp apart. And so no one who has not written a lot of macros is really in a position to compare Lisp to other languages. When I hear people complain about Lisp's parentheses, it sounds to my ears like someone saying:

"I tried one of those bananas, which you say are so delicious.
The white part was ok, but the yellow part was very tough and tasted awful."
-- Paul Graham

Lisp is about rising above implementation to saying something of lasting
value. -- Kent Pitman

Pascal is for building pyramids -- imposing, breathtaking, static structures
built by armies pushing heavy blocks into place. Lisp is for building
organisms -- imposing, breathtaking, dynamic structures built by squads
fitting fluctuating myriads of simpler organisms into place.
- Alan J. Perils

Puns are pricey to have in the language becuase they lead to ambiguity
but they are also a source of great expressional power, so we live
withthem. People who don't like them should probably seek out Scheme,
which tends to eschew puns, for better or worse.
-- Kent M Pitman @ comp.lang.lisp

Q: How can you tell when you've reached Lisp Enlightenment?
A: The parentheses disappear.
LISP has survived for 21 years because it is an approximate local
optimum in the space of programming languages.
-- John McCarthy (1980)

``Lisp has jokingly been called "the most intelligent way to misuse a
computer". I think that description is a great compliment because it
transmits the full flavor of liberation: it has assisted a number of our
most gifted fellow humans in thinking previously impossible thoughts.''
-- "The Humble Programmer", E. Dijkstra, CACM, vol. 15, n. 10, 1972

Lisp is like a ball of mud--you can throw anything you want into it, and
it's still Lisp".

Java was, as Gosling says in the first Java white paper,
designed for average programmers. It's a perfectly
legitimate goal to design a language for average
programmers. (Or for that matter for small children, like
Logo.) But is is also a legitimate, and very different, goal
to design a language for good programmers.
-- Paul Graham

> The continuing holier-than-thou attitude the average lisp programmer...

There are no average Lisp programmers. We are the Priesthood. Offerings
of incense or cash will do.

-- Kenny Tilton at c.l.l

Dalinian: Lisp. Java. Which one sounds sexier?
RevAaron: Definitely Lisp. Lisp conjures up images of hippy coders,
drugs, sex, and rock & roll. Late nights at Berkeley, coding in Lisp
fueled by LSD. Java evokes a vision of a stereotypical nerd, with no
life or social skills.

In the Algol family, parentehses
signal pain. In the Lisp family, they signal comfort. Since most people are
highly emotional believers, even programmers, it is very hard for them to
relinquish their beliefs in their associations of parentheses with pain and
suffering. This has nothing to do with aesthetics, design rationales, ease
of u

Read the rest of this comment...

Non-procedural programming

I think my favorite university course was a course focusing on "non-procedural programming." The course was half-Lisp and half-Prolog. Sure, I haven't ever actually used anything I learned in that course. But it was neat. Everytime I write code that involves parsing a text file, I always complain "I wish I were allowed to do this in Lisp." Webprogramming in Lisp would be, um, interesting. . . I've never considered that possibility before. I might buy the book just for help setting that up.

Review - Mistake

At one point you used 'for for' when you probably only meant to use one for!

Still I'll look forward to checking this book out, in the past I've done a lot of Emacs Lisp hacking but very little stand-alone lisp work, and now seems like as good a time as any to get more involved.

Once I got to grips with the way lisp programming worked it felt very natural and very powerful.

practical? common?

(if (or (= lisp practical) (= lisp common)) (monkeys-fly-out 'my-ass) (life-as-normal))

Re:practical? common?

(if (or (= lisp practical) (= lisp common)) (monkeys-fly-out 'my-ass) (life-as-normal))

I don't know what is sadder: the fact that you wrote it, or the fact that I understand what you wrote.

Dylan - pretty Lispy

Dylan [gwydiondylan.org]

seemed to have many of the benefits of Lisp without the prefix notation - macros, CLOS-based object system, multi-methods, multiple returns, optional type declarations, named parameters (I think), etc...

Dylan was started by Apple Research Cambridge in the late 80s, but was laid to rest (at least for Apple) after Jobs came back and the NeXT infusion.

At least Functional Objects opened up their stack and is now being incorporated by the above URL guys.

C++/Java/LISP Side by Side Comparison?

Lately there has been a lot of LISP hype mostly thanks to Paul Graham. I keep hearing "Macros are amazing", "totally different way of thinking about programming".

That's great and all but I can't find any concrete examples. I want to see a list of problems that are either difficult or nearly impossible with Java/C++ and see LISP's implementation.

Can anyone help me to get past the hype?

Practicle Common Lisp???!!!

Now there's an oxymoron if I ever saw one!

O'Reilly: Are you listening?

There IS a place for modern Lisp books!

If you think Lisp is impractical...

Common Lisp is more concise, more expressive and MUCH FASTER than Perl, Python, PHP, Ruby and all those other "scripting" languages. It also has better reflection, exception handling and object orientation than Java or C#. I see no reason to use those languages over Lisp, really. Does anybody who know CL actually prefer one of those languages? Note: taking a course in college does not make you "know" a language.

... programming paradigms

When I think of functional (lisp), my head's twisted and then unwinded. When I think of contraint-based (prolog), my head feels like upside-down. When I think of object-oriented, I think of org-chart. When I think of procedural, I think of spagetti.

Learn Lisp Without Installing Anything on Your PC

I have a tutorial [slashdot.org] available that teaches lisp in comic-book form. It is geared to quickly ramp up a newbie to some very advanced lisp tool very quickly.

It uses a free online telnet lisp that lets you try Lisp with zero install required.

Re:Learn Lisp Without Installing Anything on Your

Oops- Here's the link: tutorial [lisperati.com]

I Prefer the Elisp Implementation

Elisp feels very much like java to me -- everything appears to get passed by reference and you can use goops if you want objects. Guile and other variants don't behave the same way, which can catch you by surprise if you started out writing useful little utilities for Emacs. Elisp makes a lot of sense but it's not good at threading and stuff like that which other variants of lisp do have to one degree or another (Guile's threading seems to be pretty good though I haven't done a whole lot with it.)

My biggest gripe with LISP is that there are so many fragmented implementations that if you're looking for an app that does something cool (Like dynamic web page generation) it typically won't be in the variant of Lisp that you're currently using. Every time I look at Lisp, I always end up impressed with how elegant and easy it is to use. Then I start actually trying to do stuff with it and run up against the fragmentation problem and the lack of standard libraries. At least Guile addresses the library issue -- there's a whole bunch of guile code available these days.

Ha Ha!

Sissy European lisp thingy!

Best Lisp Book: On Lisp

Paul Graham [paulgraham.com]'s book, On Lisp [paulgraham.com], is the single best book on programming I have ever read. You can get it as a PDF from his website, for free [paulgraham.com].

You will also want to read his essay, Revenge of the Nerds [paulgraham.com], for some serious insight into why Lisp is just so darn good.

If you're just starting on Lisp, the best place to start is with GNU CLISP [cons.org], although you will find yourself wanting to use Emacs with SLIME [common-lisp.net] to interact with your Common Lisp environment. I use SBCL [sbcl.org], but CMUCL and CLISP are also acceptable. On my Powerbook, I use SLIME with OpenMCL [openmcl.org].

This article has truly inspired me

To wonder why there isn't a -99 "Suicidally Boring" option when you're moderating...

Lisp might be good but..

It's a pity, but lets face it: Lisp could never be adpoted for widespread use - there's only a finite number of parenthesis in the universe.

Practical Common LISP?

LISP is as Practical and Common as the Holy Roman Empire was Holy, Roman, and an Empire.

Best books are Lisp books

Have I been reading wrong books, or Lisp books are among the best books ever written about any programming language? I mean, both Graham books, this one and Norvig's Paradigms of AI include some of the best snippets I've ever encountered. Could it be that Lisp is indeed a good language?

An ideal world would run on LISP...

It's amazing and somwhat sad that programming languages and runtime environments from Smalltalk to Java to Python to C#/.NET keep reinventing the wheel while a language from the 1950s has it all and does it even better - the most elegant syntax thinkable, powerful paradigms for code reuse, dynamic typing, modern memory management with no buffer overflows, and, with Common Lisp, one robust, industrial-strength language with a rich standard library that can both interpreted and compile code, obsoleting the difference between "programming" and "scripting" languages.

The initial vision of the GNU system - remember "GNU's not Unix" - was to combine a kernel written in C for performance reasons with a userland written largely in LISP. Emacs is the only remnant of that idea, isn't even LISP in its program core, and uses its own LISP dialect instead of CLISP or Scheme. [The climacs [common-lisp.net] project, a CLISP reimplementation of Emacs, tries to fix that.]

Two years ago, I saw a practical demonstration of a Symbolics LISP Machine from 1987. It was like seeing the light of the holy hacker grail - the first system whose userland was superior to commandline Unix in every aspect [Plan9 has superior kernel design to Unix/BSD/Linux, but its mouse-centric userland sucks IMHO]. Everything was in one language, syntax and namespace. You could hack and debug the kernel (written in LISP, too) while it was running [!], the commandline userland hooked into every aspect of the system, and could be endlessly and seamlessly extended it just through custom LISP functions and eval-ing them.

Let's dream and hope that perhaps in one or two decades, when insight into the limitations of the Unix paradigm has become common sense, we will have a free Lisp OS as the next iteration of Free Software computing...

Re:An ideal world would run on LISP...

Two years ago, I saw a practical demonstration of a Symbolics LISP Machine from 1987

The frightening thing is, lispms from the 80's enjoy quite some popularity among certain people where I work [mit.edu]. They really are amazing machines, and those who use them regularly feel strongly that there hasn't been a more usable environment in all the time since they were created.

Let me tell you, though, as a sysadmin, these things can be a royal PITA. Not because there's anything wrong with them (well, except maybe for their complete lack of security) but they're just so different.

There are still many copies of The Lisp Machine Manual [acm.org] lying around, including an early rant by RMS against the recent trend of software hoarding. It makes for an interesting read...

noah

How about OS interaction

I've checked the online book, can anyone point me at some information on how to interact with the OS from clisp? I want to start/monitor kill processes, check process ids etc. From Windows (2000) and linux.

I like lisp and would like to use it but I can't find any info on how to do os api interaction.

Pointers would be appreciated, thanks.

Lisp quotes

Enjoy and contribute. [wikipedia.org].

Libraries...

I'm just getting started learning Lisp (mostly thanks to Paul), and I find myself asking repeatedly--why is it that there aren't good libraries with multiplatorm support? Is it a funding issue, where no one gets paid to so no one does it? I suspect that if it were a more popular language, it might find better support, but the catch-22 is that it needs more libraries (and thus support) to become more popular. Even then, popularity isn't the goal, so much as the byproduct of marrying a powerful language to equally useful libraries. Perhaps the word I'm looking for is more "developer-ready" than "popular".

In any case, does anyone think/know that it's possible to get Lisp to such a level or sophistication? Are major changes (*ahem* Arc) necessary to make it less "strange" without reducing power? Could the beginning programmer someday feasibly write a program in Visual Lisp, or can we not mix ease of development and powerful languages? If such a venture is possible, is anyone (even Paul) willing to support it? I suppose it retrospect it would have been fun to submit such an idea to Paul's VC setup, but I doubt it would have made it in light of the long-term nature of such development.

Thankyou Dennis

(if (or (= lisp practical) (= lisp common)) (monkeys-fly-out 'my-ass) (life-as-normal))

I would like to thank my friend Dennis, who in addition to being a MAC crank is also a LISP zealot who motivated me to read at least part of an introductory LISP manual a few years ago.

Because of him I can understand this posters joke, and I am not even on any kind of drugs.

Dennis, thanks again for all of the free, high enthusiasm lectures on LISP.

If I could wave a magic wand I would the primary concern of the I.T. industry to be about doing things right which would result in a plethora of LISP programming jobs ... most of which would be on MAC OSX platforms.

Practical

This seems to be a book about practical tasks in lisp but not necessarily practical lisp. For example, why would it be practical to do web programming in LISP instead of a platform like PHP, JSP, ASP.NET, or even Perl? All of these platforms have enormous community support for web development in terms of libraries and resources.

Am I wrong here? If not, for what tasks is LISP a practical aka appropriate, tool? From what I've seen, it's popular and presumably good for some AI work (although most of the younger AI guys I've known seem to use other tools) and it's also good for teaching students about functional programming and language theory. What else?

Practical Lisp?

I have yet to find a lisp implementation that:

1-it is open sourced.
2-it has some GUI support (tk or gtk).
3-it is cross platform (including the GUI support).
4-it is estable, not in some estate of eternal beta.
5-it is embeddable in a web server (yes, I know Mod_lisp exists. But, yet it doesn't comply with 2 or 3)

If a young language, like Ruby or Python, can do this, why the hell Lisp, one of the oldest languages around, can't?!

Until I find something like that, I can't say Lisp is practical, no matter how theoretically cool it is.

someone ought to update and simplify the language

CommonLisp has acquired lots of warts and problems over the last two decades. There is a lot of cumbersome stuff in it that isn't needed anymore (e.g., completely general floating point and character set support). There is a lot of stuff that is missing from the standard library: threads, sockets, a foreign function interface, etc. And then there is some stuff that is just poorly designed (e.g., function cells, arrays).

Unfortunately, CommonLisp is likely to be the last big Lisp standard for a long time, simply because the number of people who still bother is so smarll.

Arc would probably get widely taken up

Paul Graham's Arc is the great hope (there's a lot of interest in it at least). If it is elegant as promised I think Lispers would take it up. But, it's pretty ambitious and he appears stuck for the time being; the most recent I've heard on the subject is this comment [lemonodor.com] (2nd down) at lemonodor. He's said he intends it to be a hundred-year language and that he'll take his time, so, everyone'll have to make do with CL for the while.

My 2 cents on Lisp and FP

I have had long debates with Lisp fans and FP fans. In the end I concluded:

1. FP simplifies bad practices. If you avoid certain poor programming practices of coupling things that shouldn't be coupled, then FP's advantages are only incrimental at best. My opponents kept saying, "See what I can do with FP!", and I kept countering, "But that is not a good design" or "I don't need that feature that often", which is the truth.

2. Lisp's uniformity of syntax makes it powerful, but also very difficult to read. Other languages have syntax that acts like landmarks. Lisp is like having every house be the same such that it's power comes from the arrangement of the houses, but other languages mix in houses, stores, trailers, etc. to give visual landmarks to lock onto. Lisp is just too damned monotonous. Somewhat ugly syntax is more memorable. I tried to get "into" Lisp, but just found it too hard to visually process.

I would like to thank

the general populace here, this has been one of the more informative discussions I think I've ever seen here. some of the practical points have been very informative.

thank you.

Practical Common Lisp...

...is a contradiction in itself ;-)

Static code verifications, anyone?

I am amazed nobody mentions the lack of static code checks in Lisp. There is this ongoing confusion about Lisp compilation: detractors say Lisp doesn't have compilation, then every pro-Lisper starts refuting that, "No, you moron, Lisp HAS compilation since ages".

Well, nobody really cares if it is interpreted, compiled, JITed, you name it, as long as it is fast. But most programmers (and most important, MANAGERS) care about compilation as a way to minimize run-time errors. Heck, they love it, they are obsessed with it. Look at the extremes people go with strong-typing, building strongly-typed collections wrappers over the standard collections classes in Java and C#.

While a code base with small incremental changes can do without static code verifications, lack of it makes team work so much harder. It feels absurd for modern programmers to use a language which cannot detect that a function is missing, unless you run the program. Or for which a string multiplication with a float is just fine.

Paul Graham tells you that bottom-up programming is the best. Well, in Lisp you only have bottom up programming, because every code fragment has to be tediously verified by running it, or you are going to mispel a symbol, miss some files not included in the project, or God knows what.

Add to that the extremely fragmented Lisp runtimes and development environments, and Lisp is disappearing.

Which is a terrible shame, since Lisp has so much power and potential. I love Lisp. I would dump C#, Java and C++ for a good Lisp any day now, because they lack any serious meta-programming capabilities. We have to repeat the same stupid work again and again, because you can't build truly reusable code in these braindead languages.

What we need for Lisp is a champion who would do for the Lisp concept what Java did for the C++ concept. Modernize it. Clean it. Implement it well and completely. Allow it to become the next-generation development system.

It is going to happen, sooner or later. The "Intentional Programming" meta-programming environment Microsoft Research was developing some time ago looks for all intent (pun intended) like Lisp. Like a poor's man Lisp in fact, because those guys never understood that they needed a true computation model (which Lisp has), they were just adding features by the bunch, like they did in Windows.

Don't hold your breath for this to happen.

Talking to the OS

How does Lisp tap into a dynamic link library written in an imperative language?

Re:Good book, questionable language.

Where the hell have you been? It has better exception handling than most langauges (including java, read the book), and was one of the first languages to use garbage collection. In addition, you'll find all the normal data structures in all the other languages, threading, and so on that you're used to. CL of today is not CL of the past.

Re:Good book, questionable language.

It is new enough to contain features such as strong typing and lexically-scoped parameters that programmers today rely upon to implement OOP and RAII techniques, but programs are made unnecessarily complex by the lack of exceptions and garbage collection -- available in the most current crop of languages (C#, Java).

You are very confused. CommonLisp most certainly has exceptions, and generally speaking the implementations have much better GC than any Java you will come across.

Sheesh.

Re:Good book, questionable language.

but programs are made unnecessarily complex by the lack of exceptions and garbage collection -- available in the most current crop of languages (C#, Java).

What are you talking about? Common Lisp has both exceptions (conditions) and garbage collection.

Re:Good book, questionable language.

As everyone else that's replied to you has pointed out you are talking out your ass. Lisp had exceptions and GC long before Java or C# were even an idea. GC in Common Lisp is far ahead of GC in Java and .Net, for just this reason. An industrial strength GC isn't made over night, it's made by having applications beat the hell out of the GC and the implementors spending huge amounts of time handling huge programs. This is exactly what's happened for Lisp over the last 20 years. For example, Allegro CL [franz.com] hosts industrial applications the likes that have never even been dreamt of in Java or C#--programs that use GBs of memory and runs for months. Try that in Java or C#.

If you are still unconvinced, Orbitz [orbitz.com] wouldn't even be possible (according to the authors of the software that run the site) without Common Lisp.

Re:Good book, questionable language.

You are clueless.

Common Lisp is lexically scoped, in fact it has closures (unlike Java). 1984 it was standardized with a really powerful CLOS (CL object system), in comparison to the puny Java object system 10 years later.

Lisp also *invented* garbage collection! Without it you'd still be using FORTRAN, not Java.

And the AI comment is simply stupid. Any language can be used to do AI; Lisp is simply used for it, because it's way more powerful than Java and other crap.