Yesterday I've finished the rest of the chapters of Let Over Lambda, and my final thoughts are that this book is all about mastering code transformations. Programming in mainstream languages is like attacking problem directly or through a tool usually called library. With metaprogramming things go little bit more interesting. Lisp programmer makes a tool, that makes a tool, that makes a tool that solves the problem. Or as the old saying goes (*):
Lisp programmer available: Will write code that writes code that writes code for food.
Chapter 5 and 6 are my favorite ones, with a lot of useful examples and techniques. The bold statement that lisp isn't functional and we're proud of it certainly rings a bell, though most of the time I prefer functional style and lisp is great vehicle for programming in it. I didn't believe much in optimizations so I don't found much use of chapter 7 that gives you many example how to compile or macro transform your code into ultra efficient, high speed machine code when need arise. Finally book ends with implementing Forth, interesting stack based language, with Lisp . Final chapter felt something like a graduating case study.
Afterwards there is a nice Appendix A of what languages to learn, that I must complement with at least one language of the APL family like J or Q, and Prolog.
Appendix C covers the open source implementations which lisp has certainly has an abundance of high quality ones. But there also commercial ones which offer many additional functionality like high quality implementations of embedded Prolog (lw & acl) and Franz completely in lisp implemented databases: AllegroCache and AllegroGraph .
Appendix D covers *lisp* editors Emacs and Lisp.
My opinion is that on linux slime is the best choice but on windows I prefer commercial ides.
One little thing that bothers me in this book is author naming convention of *avoiding-asterisks-in-globals*. I don't like how some things are named in common lisp, especially I would like shorter names and removing def-something wherever possible, but in order to communicate more clearly with fellow programmers it is better to make a good use of known conventions then to invent new ones.
(*) Thanks to Rob Warnock for posting such wisdom in cll