Subject: Re: CLOS is hard. Let's go shopping  (Was Re: Lisp in Python)
From: Erik Naggum <>
Date: 18 Oct 2002 16:41:10 +0000
Newsgroups: comp.lang.lisp
Message-ID: <>

* Alan S. Crowe
| Standard book practise is to acknowledge one's technical reviewers in the
| preface, not to list them as co-authors.

  Standard book practice is for the most knowledgeable people to write the
  book and for reviewers to be at approximately the same level of general
  expertise, but not vastly superior to the author in specific expertise.

  I have reviewed books that were published and manuscripts for books that
  I recommended against publishing.  I have reviewed graduate and doctorate
  theses and advised students at both levels in specific areas.  People
  have called on my expertise in this fashion for more than 10 years.  I
  have worked with and in the publishing industry and have written four
  chapters on a book on SGML (with an incredibly helpful copy-editor that
  taught me more about English than years of study) that was not published
  because writing it caused me to decide to leave the field because it was
  impossible for me to work with such an inferior technical solution --
  something I had glossed over while I only helped people understand its
  more complicated points.  I am still credited in several books on SGML
  for having helped the authors both understand points better and for
  suggesting improvements to their writing.  Never have I seen a book
  published by a novice for novices, nor heard of such a thing, but that
  does not mean it does not exist -- the likelihood that I would purchase
  it or read it is zero, as it would undoubtedly have an off-putting title
  and cover, probably including the target audience "dummies" or "the
  complete idiot".  I recently reviewed a book in which the author could
  only be understood to apologize for his lack of mastery of the subject
  when he chatted endlessly about how hard it was to linearize the material
  and where he used more promises of what was to come and repetitions of
  what he had discussed than actual new information in each paragraph, how
  this and that feature in the topic he discussed "is not easy" to use and
  understand.  It was torture to read and try to lift it to some readable
  level.  I was quite handsomely rewarded for my effort but the book may
  never be published.  I think I speak with some authority on how reviewers
  are treated.

  When the reviewer has done much of the writing, or coaching, or even
  education of the author, the reviewers deserve to be named co-authors.  I
  quite firmly stand by this.  I know book publishing, and your tutorial
  is, with all due respect a tutorial on the Net, not a published book.

| >   But when you do this, you implicitly argue that none of the
| >   existing material is good enough
| This inference is invalid.

  No, it most certainly is a valid inference.  Such terminology belongs to
  the realm of logic, and logic is concerned with structure of the argument,
  not with the truth of its premises.  An inference does not become invalid
  simply because you disagree with parts of it.  Acquire precision!

| The merit of a tutorial is a function of the student.

  What a odd statement.

| There is no uncontroversial ordering.  The strongest inference to be
| drawn directly from my desire to write my own tutorials is that I do not
| believe that all tastes are fully catered for.

  Which even more strongly suggests that you enumerate what you have
  already read and, with no small amount of irony, explain why you are
  still a "newbie" in your own eyes.

Erik Naggum, Oslo, Norway

Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.