Let Over Lambda is opinionated, and at times, contrarian, which is the exactly kind of tech manual I enjoy reading.
The author's stance against Emacs in the appendix is surprising to find in a lisp book and resonated with me: "Emacs causes you to think about ways to write programs to do editing rather than write programs that write programs for you. You only need to script the process of editing when the code you are editing was redundantly written [...] Emacs has extension after extension, toy after toy, gimmick after gimmick for programmers to endlessly play with, be confused by, and get trapped in [...] The problem with emacs is its backwards philosophy. It treats editing as an end rather than a means. Editing itself is not an interesting process; it is what we edit that is interesting". The author prefers, not vim, but the simpler nvi. As a vi user that spent a great deal of time setting up slime and emacs, I wish I'd found more common lisp introductions that took an editor-neutral stance.
The author spends time disassembling CL code into assembly, replicating C's pointer arithmetic in lisp, jumping hurdles with macros, implementing a forth in CL, and in general, performing many other common lisp stunts which "blub" languages inefficiently handle.
> The author spends time disassembling CL code into assembly, replicating C's pointer arithmetic in lisp, jumping hurdles with macros, implementing a forth in CL, and in general, performing many other common lisp stunts which "blub" languages inefficiently handle.
Let Over Lambda is a great counter-example to the "Lisp is a very high-level language" myth, and IMO should be viewed and read as the successor to pg's On Lisp. The techniques and style of the code in LoL are a great example of what modern Common Lisp code looks like. It's a huge change from the Common Lisp code you read from the 1980s and 90s, and really different from code you see in any other language other than Racket and Scheme. The reader-macro/macro/closure DSL style of programming has just started to emerge over the last 15 years and I am excited about what other techniques come out of this style of coding.
Lisp is as high-level as a fundamentally procedural language can go; it even kind of looks functional, and it's closer to being functional than procedural language styles which scatter globals everywhere and don't use abstraction very well (IOW, the kind of code assembly language programmers and/or EEs tend to write).
However, compared to Haskell or even OCaml, it sits firmly in the procedural world.
I really enjoyed this book as well. As a self taught lisp programmer it was like looking over the shoulder of the seasoned, expert lisp programmer I've always wanted to work with but have never had the chance to do so.
I agree with the anti-Emacs sentiment for the reasons he mentions even though I do use Emacs for lisp development and think it's pretty fabulous. I don't use any of the fancy lisp editing toys, like paredit etc, and I cringe when I see developers use Emacs or IDEs to write reams of boilerplate code for them.
I've found that I need to start manually typing out code that could potentially be automatically generated so that I have the time to come to the realization that I really shouldn't be writing that code at all.
The author's stance against Emacs in the appendix is surprising to find in a lisp book and resonated with me: "Emacs causes you to think about ways to write programs to do editing rather than write programs that write programs for you. You only need to script the process of editing when the code you are editing was redundantly written [...] Emacs has extension after extension, toy after toy, gimmick after gimmick for programmers to endlessly play with, be confused by, and get trapped in [...] The problem with emacs is its backwards philosophy. It treats editing as an end rather than a means. Editing itself is not an interesting process; it is what we edit that is interesting". The author prefers, not vim, but the simpler nvi. As a vi user that spent a great deal of time setting up slime and emacs, I wish I'd found more common lisp introductions that took an editor-neutral stance.
The author spends time disassembling CL code into assembly, replicating C's pointer arithmetic in lisp, jumping hurdles with macros, implementing a forth in CL, and in general, performing many other common lisp stunts which "blub" languages inefficiently handle.