For those of you keeping score at home, there are now 11 chapters of
_Practical Common Lisp_, my upcoming Common Lisp book up and ready for
review at:
<http://www.gigamonkeys.com/book/>
As always I'm eager to hear feedback good, bad, or ugly. While I'm not
looking for widespread publicity (yet) feel free to pass that url on
to anyone who's curious about Lisp and looking for something to read.
And please encourage them to send me their feedback. I'm particularly
interested in what current Lispnots think of it (most importantly, is
it likely to turn them into Lispniks.)
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel wrote:
> For those of you keeping score at home, there are now 11 chapters of
> _Practical Common Lisp_, my upcoming Common Lisp book up and ready for
> review at:
>
> <http://www.gigamonkeys.com/book/>
>
> As always I'm eager to hear feedback good, bad, or ugly.
I still haven't read it - sorry - but from skimming through the pages it
seems to me that it is going to be a really good book, and one that
fills a need. It feels more "modern" than other Lisp books I have seen
in that it uses examples and refers to other technologies (languages,
etc.) that feel more contemporary.
Here are some random thoughts / suggestions:
- The chapter about the REPLS could be motivated along the following
lines: I guess every programmer has found themselves at least once in a
situation in which they wanted to type in an expression of their
programming language and have it immediately executed during debugging.
At least, I have felt that need several times in my Java days. There are
also things like BeanShell and Dynamic Java available nowadays for the
Java world.
You could take this as one starting point and tell the reader that a
REPL allows you to do that, and then some.
- The chapter about standard control constructs should mention recursion
and especially tail recursion. I think that this is important knowledge
even for newbies, including the fact that sometimes, for really hairy
data structures, recursion might be the best option.
Even if you don't agree with this, there will probably be people who
evaluate your book and might reject it because "it is so obvious that
recursion is best". (in quotes, because I certainly don't agree)
So it might make sense, at least, to say that the looping constructs in
Common Lisp cover all the important cases in a convenient, but that it
is important (for, say, advanced programmers) to understand recursion.
- On a somewhat comparable level, I have met people who prefer Scheme
over Common Lisp because they think that Common Lisp is dynamically
scoped. I don't have a good idea how to deal with this. Maybe a list of
the prominent features - including lexical scoping by default - on the
back cover might help. On the other hand, this might sound too academic.
Hmm... ?!?
- I like the fact that you use practical examples as motivations for
some chapters (the database example, the unit testing framework).
I think you should try to find some kind of domain-specific abstraction
for macro programming. Mario Mommer has given a nice example in his
recent talk about his language for operator equations (at the Lispniks
Cologne meeting). He said that at one stage he started to like
s-expressions so much that he just naturally started to write down his
mathematical equations with s-expressions. He then realized that he
could use what he has written without any changes by providing the right
implementation as a bunch of macros.
It would be great if you could get that feel across: First write down
how you would naturally express a solution in terms of the problem
domain, and then mold macros around that. Contrast this with the fact
that such things are usually done upside down in other languages -
usually you start to write down solutions for the problem domain in the
target language too early, and get maintenance problems as a long-term
effect.
- Another broader suggestion is this: I have read some books that
provide summaries at the end of each chapter in the form of summary
lists that mention all the important points that were discussed in that
chapter. This serves many purposes, IMHO. First it helps the readers to
check whether they have gotten the important points; it might help them
later on to remember important stuff from the book by just looking at
these summaries; and it might help you to improve the structure of the
book while writing it. These lists can also server as a basis for an
overview of the book in the introduction.
I think that this would be an improvement in general.
So, as I said, these are just random thoughts. Keep up your excellent
work! BTW, I have found the threads that resulted from your scrutinizing
questions in c.l.l very informative and productive most of the time, and
I think this serves the book well.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Pascal Costanza wrote:
> - On a somewhat comparable level, I have met people who prefer Scheme
> over Common Lisp because they think that Common Lisp is dynamically
> scoped. I don't have a good idea how to deal with this. Maybe a list of
> the prominent features - including lexical scoping by default - on the
> back cover might help. On the other hand, this might sound too academic.
> Hmm... ?!?
It could be illustrated as part of a larger point, that Common Lisp
can compile to very fast object code. Peter could include some
examples of DISASSEMBLE applied to optimized code, and mention that
lexically scoped variables can often be placed in registers.
Paul
Pascal Costanza <········@web.de> writes:
> - On a somewhat comparable level, I have met people who prefer Scheme
> over Common Lisp because they think that Common Lisp is dynamically
> scoped. I don't have a good idea how to deal with this.
I believe the correct action is to hit them over the head with a
Chineual.
Joe Marshall <···@ccs.neu.edu> writes:
> Pascal Costanza <········@web.de> writes:
>
> > - On a somewhat comparable level, I have met people who prefer Scheme
> > over Common Lisp because they think that Common Lisp is dynamically
> > scoped. I don't have a good idea how to deal with this.
>
> I believe the correct action is to hit them over the head with a
> Chineual.
I disagree.
There aren't enough Chineuals to go around.