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
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.
I am scientifically inaccurate.
Could someone proficient in LISP give me three cogent reasons to learn the language?
You can't talk about Wikipedia's flaws on Wikipedia
Dylan
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.
There IS a place for modern Lisp books!
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.
I have a tutorial 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.
Frankly, I find both Seibel's Practical Common Lisp and Norvig's Paradigms of Artificial Intelligence Programming to be much better books on Common Lisp than anything Graham has written. Seibel has excellent practical examples dealing with current technologies, and Norvig's examples cover a very interesting subject matter not usually used when teaching a 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 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 wouldn't even be possible (according to the authors of the software that run the site) without Common Lisp.
Simple. Macros turn the simple but boring work of solving a programming problem into the difficult and interesting work of extending the language you are working in.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
I'd really like to see a modern Lisp machine. I'd like to be able to pull up a Lisp console in any application I use to allow automation of any task. For example, instead of using an awkward autodownloader that can never separate the files I want from those I don't want imagine if your web browser would let you write a short program that examines all of the links on a page and downloads the ones that meet certain criteria.
I want a universal macro language and I want every program to expose the full depth of its functionality through it and Lisp is ideal for this since it allows relatively compact expressions to do very complicated tasks.
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 (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.
Someday we'll all be negroes
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.
Table-ized A.I.
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.
What a waste indeed - that Lisp programmers are blind to the real possibilities of real modern languages. I'm not talking about C++, Java, and PHP. I'm talking about ML, Haskell, Ruby. Languages that can do all the useful things Lisp can do, and many things Lisp makes incredibly difficult. And do them faster, or more conveniently, or with a syntax that even programmers whose brains have been poisoned by exposure to C are able to accept.
I suggest you Lisp programmers open your eyes to what's happening in the interesting parts of the modern language community. You'll find a lot that looks just like the Lisp you love - and a lot of new things you would never have believed were possible.
Yeah, it's a terrible shame that all those incredibly intelligent mathematicians and engineers behind Lisp didn't have cahiha to advise them about the concept of engineering tradeoffs.
They did, actually. I told them (as did lots of other people) even back when Lisp was more hyped up than Java has ever been and people were dropping $100k for a single Lisp-based workstation. They just weren't listening. The result of their lack of good engineering sense and arrogance was the demise of Lisp and the predictable (and predicted) 20 years of dark ages of C/C++ programming. It just boggles the mind that 20 years later, people like you still don't get it. I guess hindsight isn't 20/20 after all.
I won't even say anything more about Java, since I don't like the language, other than that you seem to know very little about its actual capabilities. For Python vs. Lisp, read Norvig's article.
You are complaining about dynamic programming in general. The compiler cannot always detect that a function is missing because the function does not even have to exist until runtime. I can build up functions in the program and call them. I could load a compiled file which contains the function at runtime. I could call a function by name, and that name may not be known until runtime.
You claim to love Lisp, but I don't think you have really ever sunk your teeth into it, otherwise you would understand that what you gain with Common Lisp's dynamic nature makes up for what you lose in compile time error checking. I'm a big boy, I don't need the compiler holding my hand and telling me that function x is not found or that argument y is the wrong type. My code runs correctly because it is written correctly. I just use tools besides compiler type checking to get it to this state.
If you are going to use Lisp for anything practical, you have to deal with the fact than any programming platform you choose is a combination of base language, libraries, dev tools, documentation, implementations (at several levels), other programmers, etc.
The Lisp aspect that Lisp lovers (like me) tend to like most is in the most fundamental notions of the "idea of Lisp". A very small toolbox of ideas that are combinable in an amazingly flexible way, allowing a layering of totally customizable abstractions. The power of such an approach is intoxicating, leading to a real love of the language for so many people.
The basic ideas aren't the problem. They are so pure and simple that they are almost timeless, like a branch of mathematics.
Lisp's problem is that those ideas don't exist in a vacuum. When you need to use Lisp for practical purposes, you have to deal with all the other aspects that come along with a platform, and those are stuck in a time warp.
While the fundamental ideas of Lisp are as fresh today as ever, fresher than the ideas of more mainstream languages as any Lisper will tell you (endlessly), the non-fundamental aspects of Lisp, such as the myriad design decisions in the Common Lisp version of Lisp, reflect design decisions optimized for the constraints of the computing industry of the Apollo Space Program era.
The fresh, powerful, timeless, amazing ideas of Lisp are inseparably intertwined with obsolete baggage (technical and marketing) that users of mainstream languages don't want to, and don't have to, deal with.
A New Lisp, where the timeless aspects are retained, but the other design and marketing decisions reflected today's circumstances could be terrific. Paul Graham has been talking about that for years now, essentially preempting anybody else by increasing their risk of irrelevance while refusing to deliver so much as an annual status report.
Any mention of a New Lisp to Common Lispers is like throwing water on a cat. They hiss and shriek that Common Lisp is so close to perfection that nothing needs to be changed beyond "a few libraries". It seems they have to convince themselves of that because there is so little life in the Lisp community that no one CAN produce a new Lisp. They're stuck with the old one, so they elevate it to almost the status of a religion. Those who require a more modern complete system leave Lisp (for inferior languages in superior systems), and only the True Believers remain to console one another and hiss at outsiders who ask the natural questions about the emperor's wardrobe.
What a mess....
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
There is quite a lot I could say about this, but I'm going to focus here on just one point:
Managers would care a lot less about handling runtime errors if static languages didn't just plain segfault when they get them. Error handling in non-Lisp languages is so bad that of course people outside of Lisp are obsessed with handling errors. Even Java, which drew from Lisp in its design, failed to pick up the notion of "restarts" and so only has the throw-style environment=wrecking error handling. That is severe and it's no wonder managers think it matters.
Also, the number of NULL problems you get in many static languages all by itself makes me distrust the confidence factor that managers put in static compilation. The number of wrong-type-data problems I've seen in Lisp pales by comparison to this one unchecked "detail" in these static languages.
And besides, there are other kinds of errors you can get that are just as severe but not as easily seen as type errors, and that lots of times people in static languages don't check for because they're so relieved their program runs at all. While Lisp programmers, not having this safety net, write much better tests. Tests for things other than just type match and nullness, I mean. Tests to do things like see whether the answer is right--because it's so much more easy in Lisp to represent and manipulate data that it's much easier to write GOOD test cases.
I think the process of managing Lisp projects is simply different than managing C++ projects There are a lot of details that they should account for quite differently if they want a successful outcome. This is only one of them. The paradigm shift is noticeable, I'll grant you that. But I'm not sure fixing it by making Lisp just do what other langauges do is the right fix.
Kent M Pitman
Philosopher, Technologist, Writer
Oh man, your post has so many things wrong, I don't know where to start! And I am not trolling, this is serious: dissinformation should be stopped. Read on, please.
C# and Java are more readable than C++
C# and Java are not more readable than C++. If I write C++ code without templates, C++ code is 99% similar to C#/Java.
At the end of this list are functional programming languages
Functional languages are not more readable than C++/C#/Java. ML is bareable, but a long Haskell/Erlang/O'Caml program is unreadable, no matter how you approach it. Examples: Haskell's operator ++ that has nothing to do with addition? O'caml's '#' for membership? The double ';' at the end of declarations? LISP's 'car', 'cdr' and 'cons' instead of 'head', 'tail' and 'pair'? and the list goes on...
LISP is not a functional language. It has developed to be one, but it did not start as one. In fact, it has destructive update, i.e. the SETQ operation (if I recall correctly)...
A simpler example: with Java you prevent bugs by static typing variables, example:
Having to explicitely declare the type of a variable is not static typing. Static typing is when the types of values are determined at compile-time.
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.
Bullshit. Having not to declare the type of a variable is not a primary characteristic of functional languages. The primary characteristic of functional languages is the non-destructive update of the state of the application. There are imperative languages that also have type deduction. And by not declaring types, one makes the program really unreadable, and very difficult for Intellisense editors. In fact, with Intellisense, it's just as easy.
In fact, the only difference of functional languages with imperative ones are the lack of assignment. All other capabilities of functional languages can also be found in imperative languages. There is nothing of functional languages, except lack of assignment, that can not exist in imperative languages.
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).
The only reason FP programs have fewer bugs is because assignment is not allowed. Other than that, logical bugs creep in in the usual way. All FP languages are not purely functional, and they hide state update in strange places, because otherwise it would be impossible to program. And no functional language has its primary APIs directly in that language! all the serious work (networking, DB, GUI etc) are done from C, C++ and/or Java libraries!
There are tons of other advantages but, as I said, the above links will convince you if you're smart.
Bullshit. Functional languages are glorified calculators. I can do with C++ the exact same programming, using operator overloading and list copying. Show me how to sort a 100,000 records recordset with functional programming style and then we can talk.
It was invented by Ericsson to create ultra reliable realtime servers.
Well, Linux is programmed in C and it is ultra-reliable. So is Solaris and BSD. And WinNT. And VAX. And MacOS X.
Functional languages are a waste of time. It's time to have an imperative language with the close-to-the-hardware C mentality, LISP syntax, type deduction etc that also provides facilities for proof-carrying code. That's where the money is. Functional languages are an evolutionary dead-end.
The reason that I say the
Well, it appears to be worth next to nothing. What we have there is some guy looking at a few of his projects and deciding he doesn't need static type checking. And it's not completely clear if he makes this claim because he's not making type errors, or because his type errors are being caught by his unit tests.
... An Experiment in Software Prototyping Productivity (PDF) or the less fuzzy Are Ours Really Smaller Than Theirs? (PDF). It's just some guy and his hunch...
He also makes a somewhat odd set of claims that:
a) He doesn't make type errors.
b) Dynamically typed code is easier to develop because he doesn't have to deal with build time type issues.
But... if he wasn't making type errors, then why would he have build time issues with static type-checking? I suppose I might be missing something, but what?
In any case this isn't even up to the fuzzy quality of Haskell vs. Ada vs. C++ vs. Awk vs.
-30-
It's not an odd claim to say that he doesn't make type errors. Generally, if you're rigorous about the design of your system, the types fall out naturally. It's also important to note that Lisp code generally uses far fewer types than Java code. Java code makes a new type for everything, because that's the only real expressive mechanism Java has --- classes. Lisp is far more expressive, so types are generally created when the problem domain requires it. Thus, it's much more clear and obvious what the types of an expression are at any given point, which minimizes errors.
Ask a Python programmer how often he makes type errors. After the first few weeks of using Python, I realized I very rarely made type errors. That's partly because my code was much simpler, shorter, and more logical than the equivalent C++ or Java code.
As for (b), the insight your missing is type checking is fundementally a way of declaring a contract. The problem is that C++ and Java force you to declare that contract whenever you use a variable, instead of just when it makes sense. Consider a producer/consumer problem where the product is passed between some number of intermediaries. Logically, type contracts only need to be enforced between the producer and the consumer --- the intermediaries don't care what the types are. In C++/Java, you can't do that. You're either forced to pick a type, and then forced to change all the intermediaries when the producer/consumer changes, or you're forced to create yet another class heierarchy, just to insulate the intermediaries from those changes. That's why Java code tends to have such overengineered heierarchies --- the language prevents the programmer from making more rational ones. Think of why every popular Java IDE has a tool to automatically 'refactor' the code when a type changes. If you think about it, it's an enormous hack. It's just an automated way to do grunt-work that is only necessary because the language is too limited to express what the code really needs to say.
A deep unwavering belief is a sure sign you're missing something...