On Lisp

A personal book of Harri Pöyhönen

Review

Advanced techniques for Common Lisp
by Paul Graham
Prentice Hall, 1994

My comments:

  The book goes far beyond being an excellent and not common
  presentation of the LISP language.
  The first chapters present a coherent vision of software design at a
  level very accessible to non LISP users, based on bottom-up layered
  design and functional programming.
  The core of the book goes deep into macros.

A few extracts:

p v
Bottom-up design is becoming more important as software grows in complexity.
Programs today may have to meet specifications which are extremely complex,
or even open-ended. Under such circumstances, the traditional top-down
method sometimes breaks down. In its place there has evolved a style of
programming quite different from what is currently taught in most computer
science courses: a bottom-up style in which a program is written as a series
of layers, each one acting as a sort of programming language for the one
above.

p 2
It may be difficult to say why the old method fails, but that it does fail,
anyone can see. When is software delivered on time? Experienced programmers
know that no matter how carefully you plan a program, when you write it the
plans will turn out to be imperfect in some way. Sometimes the plans will be
hopelessly wrong. Yet few of the victims of the plan-and-implement method
question its basic soundness. Instead they blame human failings: if only
the plans had been made with more foresight, all this trouble could have
been avoided. Since even the very best programmers run into problems when
they turn to implementation, perhaps it's too much to hope that people will
ever have that much foresight. Perhaps the plan-and-implement method could
be replaced with another approach which better suits our limitations.

p 5
The Lisp style of programming is one that has grown in importance as
software has grown in complexity. Sophisticated users now demand so much
from software that we can't possibly anticipate their needs. They themselves
can't anticipate their needs.

p 213
Patterns in code often signal the need for new abstractions. This rule holds
just as much for the code in macros themselves.