
Let Over Lambda (2008) - weavie
http://letoverlambda.com/index.cl/toc
======
chollida1
Would highly recommend this book, with the caveat of only if you are a common
lisp user with a fair bit of experience using common lisp.

This book goes into some of the more advanced uses of macros and I don't
believe most carries over to other "lisps".

I really loved the section on reader macros!! That's a topic that doesn't get
enough attention from people coming to common lisp.

I don't believe clojure, for example, supports user defined reader macros,
atleast I can't remember it having them the last time I used it(circa 2011).

 __EDIT __, it looks like clojure does have reader macros now. Clojure just
keeps getting better:)

[http://en.wikibooks.org/wiki/Learning_Clojure/Reader_Macros](http://en.wikibooks.org/wiki/Learning_Clojure/Reader_Macros)

In addition to Let over Lambda, my common lisp reading list includes:

[http://www.amazon.ca/Lisp-Small-Pieces-Christian-Queinnec-
eb...](http://www.amazon.ca/Lisp-Small-Pieces-Christian-Queinnec-
ebook/dp/B00AKE1U6O)

[http://www.amazon.ca/Compiling-Continuations-Andrew-W-
Appel-...](http://www.amazon.ca/Compiling-Continuations-Andrew-W-Appel-
ebook/dp/B00E3UR010/)

and [http://www.amazon.ca/Paradigms-Artificial-Intelligence-
Progr...](http://www.amazon.ca/Paradigms-Artificial-Intelligence-Programming-
Studies-ebook/dp/B003VWBY1I/)

I'd love to hear if anyone else has book recommendations in a similar vein.
I'm in the middle of a month off to read books and research papers so this is
pretty timely for me:)

~~~
davidrupp
From the wikibooks page: "At this time, Clojure does not allow you to define
your own reader macros, but this may change in the future."

Rich Hickey has been pretty adamant about not wanting to provide user-defined
reader macros, so I do not expect this to change, wikibooks' optimism
notwithstanding.

~~~
greenyouse
> Clojure does not allow you to define your own reader macros

Yeah, the reader macros on that wikibooks page are built into the language.
The best the Clojure offers are tagged literals[1] but these run after the
code is read (so they're not reader macros).

[1]
[http://clojure.org/reader?responseToken=08f63df34820f8da967f...](http://clojure.org/reader?responseToken=08f63df34820f8da967f82d777b5054c9#The%20Reader
--Tagged%20Literals)

------
kingmanaz
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.

~~~
sedachv
> 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.

~~~
cbd1984
> "Lisp is a very high-level language" myth

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.

