At one time, just prior to C89, there was some serious thought
given to collecting the c.l.c articles of Chris Torek for
publication as a C tutorial. That became a moot when the
Standard was released ...
I must also note that there is an enormous difference between
a "collection of vignettes" and a "complete novel", as it were.
However, I wonder if Chris has ever given any thought to the
specifics of his writing style? And if he would be willing to
consider a tutorial for writing technical articles for Usenet?
Or, maybe even just a few words on the subject?
I am not really sure what you mean by the first question. As for
the second or third -- well, it would help if I knew how I do it.
I think there are a few key points, however, that I could mention.
The first is simple enough. If you want to write good code, you
should read good code. If you want to write good prose, you should
read good prose. If you want to write good tutorials...
Obviously, you must know the material. But in this case there is
a subtler, yet key, point: you must also know the audience, after
a fashion. Here, Usenet has an advantage over books, because the
writers interact (to whatever limited extent) with their readers.
This means that the writer gets *some* feedback -- at the least,
something on the level of "oh I get it" vs "huh?" -- now and then.
Finally, there is no substitute for sitting back and thinking.
People say that Feynman's method of solving physics problems was:
(1) write down the problem; (2) sit and think; (3) write down the
answer. Not everyone can be a Feynman, but just about anyone can
do the "sit and think" part now and then. I think (after sitting
and thinking
) that this is probably the hardest part of the
whole process, not just to do but to explain. How is it that we
(sentient beings in general) make connections and analogies? How
do we generalize? How do we test a generalization once made? (I
often resort to the "throw a few examples at it to see if they
pass" test, as if testing spaghetti for doneness by whether it
sticks to the wall. It works well for a first cut, at least.)
Computer programming is, at its heart, about abstraction --
controlling complexity by removing irrelevant detail, at the point
where it becomes irrelevant. I am not at all sure that tutorial-writing
is about abstraction. It seems different, somehow. Certainly
there are people who are quite good at one and terrible at the
other. But some of the elements are the same: programs can be
terribly complex, and often the only way to get them right is to
simplify them. This gives rise to program structures, including
data structures. Tutorials likewise need structure, so that details
appear only where they are relevant. But the structures themselves
are different, or at least, have quite different constraints.
Well, that seems quite a few words for saying "I don't know", but
I am prone to a certain prolixity.
There is really only one
part that I am sure of: if you want to write, you must read, read,
read.
