One of the most powerful features of Lisp is the ability to mold the language through syntactic transformation. This tool, though indispensable at times, is often overused to the detriment of readability and maintainability. This blog entry gives a good summary of how to decide whether a particular task is best tackled by a macro or some other means.
The condition handling system in Common Lisp has a very rich feature set compared to the error handling features in commonly used languages today. Kent Pitman wrote a paper entitled "Condition Handling in Common Lisp" for a book, published in 2001, about advances in exception handling techniques. It's a great overview of the history of error handling techniques in programming languages as well as a great overview of how Lisp handles the issue.
If you've ever been curious about what a typical Lisp development environment is like, or about how a Lisp web programming framework would work, here's a great video (torrent link) for you.
The video shows off a number of cool things. First, there's SLIME, the most advanced Emacs mode for Common Lisp development. It's got several IDE features that make Lisp programming far more comfortable than it would be without them. Second, there's UnCommon Web, a Common Lisp continuation-based web development framework. It looks to be pretty nifty for web apps that need control flow.
At the recent International Lisp Conference, John Allen presented a paper entitled "History, Mystery, and Ballast" in which he gives the early history of the engineering discipline and draws an analogy between engineering of that time period and current software development practices. As physical and electrical engineering are constrained by the laws of physics, software is constrained by the laws of mathematical logic, and he hopes that a stronger theoretical basis and disciplined training will eventually supplant the mostly ad-hoc techniques of the current software shop culture.
In addition to the interesting historical aspects, he also gives an overview of the mathematical theory (constructive logic, lambda calculus, Curry-Howard Isomophism, etc.) that could serve as a basis for a software engineering discipline that creates predictable software, as he calls it.
I'm currently taking a Java class in school. It's a pretty basic class, but I have a new perspective on it now that I'm familiar with a larger range of languages. When we discussed anonymous inner classes, I immediately recognized them as closures. I was anxious to find just what you could accomplish with them, so I did a bit of research online. First, I found a wiki page describing an implementation of Smalltalk-like code blocks in Java. These are cool, but syntactically awkward in Java. Via that page, I found a very interesting essay regarding Iterator objects, and how they are a sign of a weakness in a language. Finally, I came across a Koan regarding the similarity of objects and closures.