Lorin Rivers writes:
> I sure wish there was a book that explained how to think like a
> programmer, e.g., what are the essential, non-language, non-platform
> truths about programming.
Well, the problem is that there are multiple levels of skill needed
--- for a quick ten-liner, all you really need to know is that
computers follow instructions, but as programs get larger, you need to
be increasingly aware of how the data and control structures of your
program reflect the structure of the problem that you're trying to
solve (if the program isn't to dissolve into an unmaintainable mess;
see http://www.laputan.org/mud/mud.html).
This is one of the things people like SICP for, I think --- but the
problem with SICP is that the really detailed examples are things like
meta-circular scheme interpreters, compilers, and CPU simulators. You
need moderately deep technical background just to understand the
problems that these programs are trying to solve, and if you don't
understand the problems, then you *can't* understand how their
structure is reflected in the structure of the programs.
I'm not sure I know of a similar classic for smaller programs, of
the sort that users more directly have to deal with. Twenty-five
years ago, "Programming Tools" by (IIRC) Kernighan and Plauger was
widely cited; it includes a line-oriented text editor and the like.
But almost nobody uses line editors these days, so these still aren't
programs that do a job that you'll have had much direct experience
with.
There are several books which I haven't read, but for which I've seen
some praise --- including, BTW, further books from Kernighan, Pike, et
al. about the philosophy of programming; depending on the examples,
these may be helpful.
Another thing you might want to look at is "Programming Pearls" by Jon
Bentley; it's a collection of what were originally columns in CACM,
which includes a couple of essays on how to decompose a problem so
that you come up with a solution that fits, and how to evaluate
potential solutions. The examples are small, almost bite-sized, but
in a few cases he manages to make a virtue of that, by showing how a
little thought about the nature of the problem lets you *avoid*
constructing programs ten times as large.
Lastly, if you're in Linux-land, you can get the source code to just
about everything you use; simply studying the code of a well-written
program can be instructive. (Or even a badly-written one; after
you've chased through a dozen files to find out which one is doing
some magic with a global variable someplace, you'll have a gut-level
understanding of what's wrong with global variables which is otherwise
difficult to convey).
rst
This archive was generated by hypermail 2b29 : Fri Apr 27 2001 - 23:17:44 PDT