Subject: Re: CLOS is hard. Let's go shopping (Was Re: Lisp in Python) From: Erik Naggum <erik@naggum.no> Date: 18 Oct 2002 16:41:10 +0000 Newsgroups: comp.lang.lisp Message-ID: <3243948070365135@naggum.no> * 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.