PAPERDATA

It's easy to feel that the glut of computing books forgo the rudiments of the craft and settle for lots of games for the frogger freak. But, asks Alan Jowett, could it be that the authors of these texts ignore a rather vital question. What is a book?

GOON-CRACK IT!

Watching the hordes in W H Smith clutching at books geared to their own machines leaves you wondering how wide their view of the world is. Because buying a Spectrum doesn't mean you've started using your brains yet - the box can't actually do anything on its own. Few programming books tell you that one of the most important skills is patience; knowing how to debug is all about mind over matter most of the time. Walking the dog, reading poetry, listening to Brahms might help, but the books don't contradict the idea that the micro is what's all important. It's easy enough to pick up a smattering of Basic and learn how to doodle a bunch of pixelated munchkins all over the screen, but the books don't encourage you to ask any of the global questions.

The best programming book I've seen over the past two years had not a single program in it and was nothing to do with the Spectrum or any other machine. But Design and Memory (McGraw Hill - John Wiley, £8.50) is the one I'd take to that desert island.

Full of wisecracks aimed at programmers in big corporations it's still highly relevant to Spectrum users - after all, a lot of us have 48K at our fingertips and that was more than mainframe power only a few years ago. Peter Huyck and Nellie Kremenak urge programmers to get themselves to think of people as being useful, and to discover how the machine can help in their own lives. Too many Spectrum owners get their value out of the machine as a quick thinking toy, never seeing it as a way of helping to develop themselves.

OK, so you don't want to learn archaic algebraic formulae. But, as the book points out, a good programmer is much like a jackleg carpenter - and they don't read philosophy either. And snippets of Reader's Digest aphorisms filtered through MAD magazine keep cropping up, telling you to summarise the condition of humankind in 25 words or less, or to cycle down to Kitty Hawk and feel the breeze coming from the South. Find one aspect of programming that inhibits innovation, they urge. Their approach is that there are only four billion of us at the moment and you can't assume that somebody else is asking those vital questions.

We're all getting the benefit of immensely clever chaps like Sir Clive and his Mensa friends. But let's not pretend there aren't holes in our ways of looking at the world.

Logic is flexible but too many programmers are too rigid and impatient to try trial and error methods. Librarians are just the same. Huyck tells the parable of how titles of books in Oriental languages are transliterated into the Roman alphabet and filed by the ordering rules for English titles. The rules are devised by Westerners but most people looking for books in Oriental languages are Orientals, so no one can find anything in the Oriental collection.

Logic, philosophy and programming are all useful to each other. Bits of informed approaches will rub off on micro programmers over the years, but not if we just stay put in front of the same half dozen reliable guides. Don't just look under the safe old Dewey code of 001.642 in the library stack - let your fingers walk a few inches on both sides. After all, life is a bit of an adventure.