Slashdot Mirror
Practical Common Lisp
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
Sorry, had to be said.
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...
http://students.washington.edu/djwatson
"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"
Your assumption that all self-modifying and/or recursive code is spaghetti code belies the fact that you've never actually learned Lisp.
I have always found that spelling and grammar skills are very important to good coding, as well. After all, it helps immensely to be able to spell your variable names correctly. Even if you spell them incorrectly consistently, someone else who is looking for the bugs in your code will probably decide that one of the bugs is your spelling, and will break more things than he fixes, particularly if you used the correct spelling for another variable.
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.
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 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...
I swear I would rather chop off my left hand then program in Tcl ever again. But I won't hold your love of Tcl against you :-) My favorite behaviour when using Tcl was seeing a syntax error in code that had been running in production for years. Since Tcl isn't preprocessed god only knew how many syntax errors where in that code. Granted the programmer should have written test cases to exercise all of the code, but that is a whole other ball of stupidity.
I Am My Own Worst Enemy
- 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 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 and Erlang (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 PC.
There are tons of other advantages but, as I said,
- -- Truth addict for life.
Or the sig of a CS prof at my undergrad school:
Today is the car of the cdr of your life.
CL sufferes from the ugly stepchild syndrome. Its so ugly that the only reason its still around is because it is faster than the nice looking alternative (think scheme). Also compare to ML vs. Haskell, C++ vs. Objective-C, etc.
"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."
I only have two things to say to that.
"<" and ">"
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 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...
gopher://cramer.plaintext.cc http://cramer.plaintext.cc:70
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 and start over.
an ill wind that blows no good
It can be handy during debugging. I don't recommend using cdaadr (et al) in production code.
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.
Wrong. Lisp has parentheses in specific places, leaving no doubt about where you're supposed to put them. Adding excessive parentheses to Lisp code changes it.
And the parens and the code-data equivalence do have a purpose. They make working with the code programmatically very easy, which allows Lisp macros. The macros that every Lisp fan always mentions. They wouldn't be nearly as useful if Lisp didn't use the parentheses. And the parens are amazingly easy to edit with proper editor support.
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.
Comment removed based on user account deletion
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.
when you choose to abandon LISP in favour of, say, static type checking, his insistence that all great hackers prefer LISP, and if you don't prefer LISP you aren't a great hacker, begins to grate somewhat.
Yes, that's my biggest problem with his writings. I rather like static type checking personally, and will gladly trade the minor benefit in malleabillity for more error checking at compile time. I can't count the times I've made a trivial typo in Perl, for example, taken hours to find it and then thought to myself, "this would have been caught instantly in ML."
While LISP is a cool language, I really like what I've seen of the strongly static-typed functional languages like the ML family (especially OCaml.) I love the pattern matching features for example. The only thing I miss in them is the macro mechanism from LISP or Scheme and the extreme performance optimizations of modern C++ compilers. I do heavy-duty numerical coding in C++ (graphics/ray tracing), but I'd love to be able to write code in a statically-typed functional language, have macros expand out and optimize or inline the low-level, performance critical parts and have the compiler optimizer work it over till it's as fast as I'd be able to do in C++. (or faster!)
So yes, I consider myself a pretty good code-hacker, but I'd still not pick LISP for my graphics code. LISP is not the right tool for every job.
It seems difficult to you for the same reason Japanese seems difficult to native English speakers, and English seems difficult to native Japanese speakers.
Don't drop the soap, Tommy!
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?
---anactofgod---
"Equal opportunity swindling - *that* is the true test of a sustainable democracy."
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.
Everything else is just now catching up. Evidence all the effort to fold in Lispy features into Python, Perl, Ruby, etc., etc.
Engineering is about making tradeoffs--something that the designers of Lisp did not understand. If you try to create a completely general language with completely general language constructs, you try to standardize it, and you try to also make it fast, something has to give. And the thing that gives is development time.
Python, Perl, and Ruby can afford to implement lots of Lispy things because they aren't also trying to create a language standard and efficient, natively compiled implementations. Java is also implementing lots of Lisp things, but it makes other tradeoffs (which result in it being more cumbersome in some ways).
While Lisp Just Works.
That's a stupid statement: nothing "just works" for everybody. And CommonLisp had lots of problems: scoping, naming, reflection, and code generation are all pretty shaky in CommonLisp. Its standard library also had lots of important omissions. If CommonLisp "just works" for you, consider yourself lucky. Frankly, I think the number of people for whom, say, Python "just works" is considerably larger than the number of people for whom CommonLisp "just works".
But I think the "magic" here in LISP is that by going at it with macros and using those to change the appearance of your programs, you're providing a sort of cognitive shift to the programmer where they can think about each category of problem in the system as a "mini-language". That renders a way for the programmer to feel like they're in control and like the solution feels more elegant, because it's less encumbered by syntactical baggage. Is that about right in your experience?
That's exactly right. Those who continually respond "but I could do that in [Blub]" are missing this point. The approach is known as writing a "domain specific language" (DSL) or, as Paul Graham calls it, "bottom up programming". Instead of trying to reduce your problem to the level of a general purpose language like Java or Python, you bring the language up to meet your problem domain. In effect, you create the language best suited to solving your problem, then solve the problem with it. The end result is a leaner, tighter program which is less encumbered not just by syntactic baggage, but semantic baggage as well. Every line of code you don't have to write is a line of code you don't have to understand and support later, and Lisp macros allow you to save hundreds and even thousands of lines of code throughout your application's code base.
Tcl however lack the "robust abstraction" nature of Lisp. Instead, has "everything a string" nature.
Personally, OOGG feel any language where "value of variable" needs $ notation is severely brain-damaged. Absolute opposite of abstraction.
No, what's given rise to the sluggish crap is implemeting everything in C. Take Gtk, which would be much faster if it was written in a language which actually supported its object model. As it is, the code's clogged up with kludges to string together some kind of OO support and it's slower than it would be if it had been written in C++.
And, although I don't expect you'll listen, Lisp is an efficient language. It compiles to fast machine code.
Freedom is not increased by mere diminuation of government. Anarchy is freedom for the strong and slavery for the weak.