The main novelty here is that the author just made the entire book available to the public for free.
I have previously read the printed version, so maybe now is a time for a very brief review. The book is technically fascinating and a worthwhile read, but it is also highly opinionated even by Lisp standards. Then again, it is refreshing in this time and age to see this deeply human and creative side of programming. I wholeheartedly recommend others to read it - and to carefully choose which of the advice to follow and which not :)
Thank you so much, Doug Hoyte, for making this book available to all of us!
I bought and read Doug’s book years ago, glad to see it surfaced here with the announcement that a PDF and HTML version is available.
I have been programming in Common Lisp since the early 1980s, love the language, but I just use the language simply. That said I like the things that Doug, Paul Graham and others write about great Common Lisp techniques.
I read the book years ago, and while I think it's interesting, today I think it's better to learn lambda calculus directly, without the Lisp "gimmick".
The book is wonderful to read and get your mind blown by all the ingenious, clever, and surprising things that are possible using basic building blocks of Common Lisp - so that you know exactly what code you should NOT be writing when doing Lisp for anything serious and involving other programmers.
It's very good for realizing the difference between what is possible and what is feasible, since Lisp mastery requires both knowledge of what is possible to do and restraint in the actual use of those possibilities. Clever things require cleverer debugging techniques, and Let Over Lambda is absolutely full of the former.
Yeah, its pervasive use of explicitly, deliberately nonhygienic macros was surprising when I first read it. Interesting to consider and also good to understand why it'd be a nightmare to debug code written that way.
There is plumbing code and there is porcelain code. There is nothing wrong with being clever in the plumbing area, even with other people peeking under the hood. The porcelain side is more nuanced though - it takes a special kind of cleverness to deliver intent with clarity.
A personal anecdote - not long ago I saw a beautiful piece of code (not mine) using the Result monad being rewritten as a chain of nested if statements - all because it was "too clever to understand". Go figure.
> There is nothing wrong with being clever in the plumbing area, even with other people peeking under the hood.
Sure, with proper documentation and comments and enough modularity to refactor this code as necessary - your example of moving between Result and an if-chain is an example of this.
The Result example illustrates this debate nicely. Software is composed entirely of abstractions, even down to the machine code level. You have to understand the abstractions to use them effectively.
"Too clever" is subjective, and often just means that the developer lacks sufficient familiarity with the abstractions, such as Result in this case.
The abstractions are what allow us to build systems with intrinsic complexity and keep them manageable. The "too clever" accusation is about perceived complexity, and depends on the observer. Expertise changes what seems complex or simple to someone.
The main novelty here is that the author just made the entire book available to the public for free.
I have previously read the printed version, so maybe now is a time for a very brief review. The book is technically fascinating and a worthwhile read, but it is also highly opinionated even by Lisp standards. Then again, it is refreshing in this time and age to see this deeply human and creative side of programming. I wholeheartedly recommend others to read it - and to carefully choose which of the advice to follow and which not :)
Thank you so much, Doug Hoyte, for making this book available to all of us!
so the date in the title is wrong
I bought and read Doug’s book years ago, glad to see it surfaced here with the announcement that a PDF and HTML version is available.
I have been programming in Common Lisp since the early 1980s, love the language, but I just use the language simply. That said I like the things that Doug, Paul Graham and others write about great Common Lisp techniques.
I read the book years ago, and while I think it's interesting, today I think it's better to learn lambda calculus directly, without the Lisp "gimmick".
> I think it's better to learn lambda calculus directly, without the Lisp "gimmick".
The book isn't about teaching lambda calculus, though. It's covering things you can do in Common Lisp, specifically around macros.
Looks like the well known book has just become free (online or PDF)
The book is wonderful to read and get your mind blown by all the ingenious, clever, and surprising things that are possible using basic building blocks of Common Lisp - so that you know exactly what code you should NOT be writing when doing Lisp for anything serious and involving other programmers.
It's very good for realizing the difference between what is possible and what is feasible, since Lisp mastery requires both knowledge of what is possible to do and restraint in the actual use of those possibilities. Clever things require cleverer debugging techniques, and Let Over Lambda is absolutely full of the former.
Yeah, its pervasive use of explicitly, deliberately nonhygienic macros was surprising when I first read it. Interesting to consider and also good to understand why it'd be a nightmare to debug code written that way.
There is plumbing code and there is porcelain code. There is nothing wrong with being clever in the plumbing area, even with other people peeking under the hood. The porcelain side is more nuanced though - it takes a special kind of cleverness to deliver intent with clarity.
A personal anecdote - not long ago I saw a beautiful piece of code (not mine) using the Result monad being rewritten as a chain of nested if statements - all because it was "too clever to understand". Go figure.
> There is nothing wrong with being clever in the plumbing area, even with other people peeking under the hood.
Sure, with proper documentation and comments and enough modularity to refactor this code as necessary - your example of moving between Result and an if-chain is an example of this.
The Result example illustrates this debate nicely. Software is composed entirely of abstractions, even down to the machine code level. You have to understand the abstractions to use them effectively.
"Too clever" is subjective, and often just means that the developer lacks sufficient familiarity with the abstractions, such as Result in this case.
The abstractions are what allow us to build systems with intrinsic complexity and keep them manageable. The "too clever" accusation is about perceived complexity, and depends on the observer. Expertise changes what seems complex or simple to someone.