Re: This one goes to 11

From: Pascal Costanza (costanza_at_web.de)
Date: 12/09/03 

Date: Tue, 09 Dec 2003 01:02:03 +0100

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

Relevant Pages

  • Re: CAS, Lambda Calculus, Continuation and Functional Programming
    ... There are no expressions in Fortran or Pascal??! ... expressions are programming language constructs that return a value. ... > languages don't have recursion. ...
    (sci.math.symbolic)
  • Re: F#
    ... they have chosen Common Lisp _because_ of the ... The efficiency of a program is very hard to predict, especially for large programs, and the programming language and implementation thereof that is used is only one of many different factors. ... Knowing a success story only tells me that other people ...
    (comp.lang.functional)
  • Re: Interesting article by Joel Spolsky: The Perils of JavaSchools
    ... > recursion to define an ordered set, that does not imply (as you imply ... programming in something like Java. ... >>> abandon Java in favour of a toy language that is limited to them and no ...
    (comp.programming)
  • Re: Statically AND Dynamically Typed Language ??
    ... I haven't been able to do even that in my daily programming ... That's a strange claim - the old default ranking for Pentium 4 seems ... on tail recursion, simple vectorization etc. ... If the language implementation doesn't provide a way to use simple ...
    (comp.lang.misc)
  • Re: CAS, Lambda Calculus, Continuation and Functional Programming
    ... >> the programming style of symbolic math packages as partly functional ... see that I strive to learn the language which we use to understand the ... languages don't have recursion. ... Thus it doesn't seem to me that lambda calculus if fully implemented ...
    (sci.math.symbolic)