Why Rev needs a cookbook (newb questions)

[Richmond Mathewson]

Apart from your obvious fixation on spaghetti  :)

The only problem about these types of recipe books is that it is 
well-nigh impossible to guess
all the recipes that will be required: after all, if it were, there 
would be no original programs
or ideas within programs.

While answers to questions such as "how to I clear a field of data?' may 
be straightforward, and,
almost everybody is going to ask that question sooner rather than later, 
questions such as

How to I download pictures, music and film clips from seven different 
websites, arrange them
across a number of cards, embedding some of the imported data in fields 
according to type,
and export selected parts into a variety of image formats?

Are rather more difficult to foresee, and may not always be capable of 
being broken down into
lesser questions demanding less elaborate and specific answers.

All of us have come across books with titles such as "Moron's guide to 
Spaghetti", and, apart from
the fact that the title's sound rather insulting, they do tend to

"talk down"

provide a 2-dimensional view of things

which may be all well and good if all you want to do is belt out endless 
plates of spaghetti-cheese
and spaghetti-with-some-indefinable-unidentifiable-brown-sludgy-sauce; 
but misses one of the
main points about cooking (and, oddly enough, computer programming); the 
creative possibility
that makes all the difference between the type of people who used to 
dish up some 'orrible filth
they passed-off as 'Four Seasons Spaghetti' at my school, and REAL cooks 
who make you rush
back for more.

Surely, one of the joys of cooking is the possibility for endless 
experimentation.

Aah . . . wait a minute . . . I seem to remember one Dr Alex Comfort . . 
. who wrote a book . . .
about . . .

Hey!  "The Joy of Runtime Revolution" complete with line illustrations 
of all sorts of interesting
object layouts.

Peter Alcibiades wrote:
> Someone suggested entering 'empty' into the dictionary.  Try it.  You get
> 30-40 entries, with 'empty' as a property, and one with it as a constant,
> and two with it as an option on commands.  One of these may or may not tell
> you how to set a variable to empty.
>
> This is a bit like setting out to make spaghetti carbonara, and discovering
> that you can look up spaghetti in the manual.  There are lots of entries for
> the diferent sorts of spaghetti, thick, thin, fresh, wholewheat...  You look
> up bacon.  Lots of entries, back, streaky, smoked, pancetta.....  What you
> need is a book organised by Things You Want to Make.  Carbonara, Bolognese,
> Cheese.   Broccoli and achovies, Putanesca...   I am getting hungry thinking
> about it.
>
> So similarly what Rev needs is a book which does not, when you look up
> 'empty' have all those 40-50 entries.  Instead it has some along the lines
> of 'How to empty a variable, field.....'.
>
> Carla's book is a model.  Here is her table of contents
>
> http://oreilly.com/catalog/9780596006402/toc.html?CMP=ILL-4GV796923290
>
> And here is an excerpt to show exactly how it works:
>
> Problem
>
> You need to know what files are installed on your system when you install a
> program from source code, so that you can find and remove all of them if you
> decide you don't want them anymore. Some program authors thoughtfully
> include a "make uninstall" target to perform a clean uninstall, but many do
> not.
>
> Solution
>
> You can use standard Linux utilities to generate a pre-installation list of
> all files on your system. Then generate a post-installation list, and diff
> the two lists to make a list of newly-installed files. This example uses
> JOE: Joe's Own Editor:
>
> # find / | grep -v -e ^/proc/ -e ^/tmp/ -e ^/dev/ > joe-preinstall.list
>
> Compile and install your new program, then generate the post-installation
> list:
>
> # find / | grep -v -e ^/proc/ -e ^/tmp/ -e ^/dev/ > joe-postinstall.list
>
> Then create a list of files installed by Joe by diffing the two lists:
>
> $ diff joe-preinstall.list joe-postinstall.list > joe-installed.list
>
> There are a few more examples here:
>
> http://www.linuxdevcenter.com/pub/a/linux/excerpt/lnxckbk_1/index.html
>
> Its all organized along the lines of, you are engaged in doing something and
> find you would like to do X,   This is how to do it.  Sometimes (as in this
> case) there is a discussion (here omitted) afterwards about how it works and
> what to be careful of.
>
> You can see, its a dictionary, but organized by problems which in turn are
> all grouped under tasks.  You need both kinds.  I am not criticizing the Rev
> materials, which are (a) much improved and (b) excellent as what they are. 
> But you do need both.  Especially for those starting out with it.  My own
> example was a problem which Jim Ault was kind enough to show me how to
> manage, using 'filter'.  Filter was there in the dictionary all the time,
> I'd just not realized that this was what you used or how you used it to
> solve my problem.  But had there been an entry on the lines of, how to
> eliminate dupes, or some ways of doing lookups and matches, it would have
> been in there.
>
> It would be natural to get contributions in the form of a wiki, and then
> have someone edit them into a structure.   Most of the material is probably
> around somewhere, just not organized like this.
>