Let Over Lambda

Let over Lambda is an exploratory journey into advanced techniques involving Common Lisp features and language properties, that can be combined in ways that result in more than the sum of their parts. There are plenty of "wow, that is cool" moments and useful constructs demonstrated, that will probably make it into the reader's toolkit. But of greater importance is the progression in how these are delivered. While not a broad tutorial in Common Lisp (although the reader-macro chapter could serve fairly well in that capacity), Let over Lambda contains an underlying tutorial on the incremental/iterative development of such macros/tools against desired requirements - building up to constructs via interim revisions and explanations. A book involving Lisp has little choice but to stand on the shoulders of giants, and by necessity these are frequently referenced and cited. The most important of these is Graham's "On Lisp" (currently available for free download) - which, while attempting to cover the breadth of the language, is regarded as one of the more advanced texts on macros. Some topics introduced in On Lisp (such as the leveraging of unhygienic macros) are taken much further in Let over Lambda, and combined with other constructs (such as capture/closures) that would have to be described separately in more general purpose tutorial or language overview. The writing style definitely includes an "attitude" that is partially inherent to the material being discussed and partially from the author's obvious passion (a passion that becomes REALLY obvious in the Forth chapter). Hoyte often highlights the blanket superiority of Common Lisp over all other languages; but to a reader who has put in the time to learn Lisp macrology in enough detail to understand this book, this isn't a particularly large stretch. Also, certain comfortable safety idioms are challenged as being more safeguards for beginners. On several occasions, the reader receives an explanation: "Here is the what and why of adhering to restriction X. Now here are the incredible things that become possible when you break it!" This is demonstrated via unhygienic macros, as well as the broader concept of "duality of syntax" - a definition that evolves throughout the book. Early in the introduction Hoyte states that macros (in a language that can leverage them) are more than just boilerplate-reduction tools for known simple cases; but that their power represents a sort of "uncharted territory" of immense potential. Certain common (seemingly) ideological arguments (things like lisp-1 vs lisp-2), were laid out against a backdrop of examples and threaded into the theme of the entire book. While often going out on a limb, the author makes his case. I was inspired by this book.

I haven't finished it, but like another reviewer I am being inspired by this book. In the first couple of chapters, the author shows examples of assembler, C and Lisp, mostly in preparation for introducing lexical closures. Closures, it turns out, are generated easily in Lisp by using the construction "let over lambda". Regarding closures, I agree with the author that most of us have been left "with the inaccurate impression that closures are only good for toy examples like counter." But in fact, "closures are the building blocks of Lisp. Environments, the functions defined inside those environments, and macros like defun that make using them convenient, are all that are needed for modelling any problem." And in fact, the author's aim is "to stop beginning Lisp programmers . . . from . . . reaching for systems like CLOS." Yes, CLOS offers certain things, but ". . . do not use [CLOS] when a lambda will suffice." If you're like me, you find all this very refreshing and stimulating. From pages 31-37, the author deftly shows how objects are collections of procedures and associated state, and how the entire object infrastructure is easily derived from the lexical closure, otherwise known as "let over lambda," and combinations of "let over lambda over let over lambda." The ease and power with which this is demonstrated is breath-taking. A couple of more quotes: "Object systems are a formalisation of a subset of let and lambda combinations, sometimes with gimmicks like inheritance bolted on (footnote 10: Having macros is immeasurably more important than having inheritance.)" And, "Once assignable value cells and good old lambda expressions are available, object systems are, at best, occasionally useful abstractions and, at worst, special-case and redundant." As I indicated, I have not finished the book, but the first couple of chapters have given me plenty to consider. I highly recommend this book.

If you know your way through the multiple flavours of Lisp this book becomes really interesting. Doug starts by explaining the basics of why one would want macros in a programming language and quickly moves on to extending the basic Common Lisp language with all sorts of new features; including a very sweet chapter implementing Forth macros. Most of the code is based on lexical closures, hence the book's title. The opinion-to-fact ratio makes the book a very hard read, though. The usual arrogance towards different language and paradigms (please forget that section on Functional Programming) is somewhat expected but makes it really hard to enjoy the text. Even though Hoyte's blind evangelism of Common Lisp is extremely annoying, he is a great hacker and knows how to reuse other people's work --even if originally written in one of the Lisps he despises. If you are fairly new to Lisp in general and Common Lisp in particular I don't think you will find it very interesting. Even if you write code in Clojure -the Lisp most people I know are exposed to these days- I would recommend that you read the fantastic Practical Common Lisp, by Peter Seibel, before trying this one. What I love most about this book is how it teaches you to think of macros as nothing but functions that return lists. The fact that these lists happen to contain code is irrelevant; macros are still functions. Full review: [...]

The book is great and presented in a very understandable manner. The book is a must have. The appendices are great.

Great

Ce livre est très intéressant et très spécialisé. Il s'agit d'une étude complète de ce que sont les macros dans le langage de programmation LISP. Si vous recherchez un livre pour apprendre LISP, ce n'est assurément pas le livre qu'il vous faut. Vous trouverez sur internet de très bonnes ressources ([...]) vu que les livres sur le sujet, étant donné l'âge du LISP, sont assez rares. Si, en revanche, vous avez déjà une bonne connaissance de LISP, que vous souhaitez étudier tous les aspects de ces objets extraordinaires que sont les macros, objets qui donnent à LISP ce caractère si particulier qui le distingue des autres langages alors ce livre est pour vous.

In Let Over Lambda veranschaulicht Hoyte zahlreiche fortgeschrittene Methoden und Ideen, einige Eigenschaften von Makros und "Closures" in Common Lisp sorgfältig auszunutzen, die bisher fast nur als gefährlich oder unbedeutende Kuriositäten betrachtet worden sind, um beeindruckend flexible, knappe und sichere Programme zu erstellen. Solche Methoden werden kurz im Buch "On Lisp" von Paul Graham vorgestellt, und Hoyte entwickelt sie weiter. (Ich empfehle Ihnen deshalb, erstmal "On Lisp" zu lesen, was sowieso ein von den besten Lisp-Büchern ist). Außerdem wird ein anderes Thema gründlich besprochen, das (so weit ich weiß) anderswo nur oberflächlich behandelt wird, und zwar: die Optimierung von denjenigen Common-Lisp-Programmen, die hauptsächlich auf Makros aufgebaut sind, mit Hilfe der modernen, quell-offenen Compilern wie z.B. CMUCL und SBCL. Hoyte gibt zahlreiche Beispiele davon, wie solche Lisp-Code in Assemblersprache übersetzt wird, und versucht das Code schrittweise zu optimieren (zum Teil auch durch Makros!), damit die Übersetzung so kurz wie möglich ist. Er bespricht dabei auch Sortierverfahren, und erstellt Programme sehr hohen Leistung (sogar im Vergleich mit C/C++), ohne dass er selber überhaupt etwas in Assemblersprache oder sonst was schreiben muss. Dadurch will er zeigen, dass es sich gar nicht mehr lohnt, in "Low-level programming languages" (den deutschen Begriff kenne ich leider nicht – auf Englisch bezeichnet das Assembler, C usw... Die Letztere wird auch mit Humor "portable assembly" bezeichnet!) zu programmieren. Es kann alles durch Common Lisp alleine gemacht werden, und diese befähigt einen, immer auf einer höheren "Abstraktionsebene" (jetzt bin ich mit der deutschen Sprache überfordert) zu programmieren, was seine Produktivität viel erhöht und die Zahl "Bugs" im Programm auf ein Minimum beschränkt. Let Over Lambda war mir ziemlich schwierig zu lesen, einfach nur, weil ich noch wenige Erfahrung (ungefähr ein Jahr) mit Common Lisp habe; jedoch ist alles im Buch gut erklärt, man muss sich aber schon ein wenig damit auskennen (wie gesagt: On Lisp). Übrigens ist Hoyte ziemlich rechthaberisch, was vielleicht einige Leser (besonders die, die sich bisher ausschließlich mit anderen Programmiersprachen und Paradigmen beschäftigt haben) nerven könnte; aber er rechtfertigt seine Meinungen durch klare und überzeugende Erklärungen sowie durch die Ergebnisse seiner ausführlichen Experimenten. Der Autor scheint zweifellos begabter Hacker zu sein, und nicht nur in Lisp, sondern auch in Programmiersprachen, die er kritisch beurteilt. Man braucht ja nicht, ihm zuzustimmen: nur aufgeschlossen zu sein, damit man seine Ideen verstehen kann. Wer Interesse daran hat, wie Programmiersprachen (und die Programmierung selbst) in der Zukunft weiterentwickelt werden könnte, soll dieses Buch lesen. Wer schon großer Lisp-Fan ist, wird unbedingt viel Spaß am Lesen des Buches haben. Und der, der immer noch nicht von den Vorteilen Common-Lisp überzeugt ist, soll es auch lesen.

It took me a while to warm up to this book. Initially I thought that it rehashed Graham, albeit poorly. I was skeptical of some of Hoyte's comments in the book. After having some time to absorb them, I see that he was right all along and in fact, his approach is superior to Graham's. I didn't think much of it at the time I first read the book but as the ideas sunk in, I became a better programmer.