in reply to YAC (Yet Another Challenge): Oldest Useful Computer Text

I no longer refer to it daily, but I still keep my ITT Advanced BASIC manual (1985 printing) where I can reach it -- not because I ever program in BASIC any more, but because the appendices have other, semi-related, useful information. It's all info that's also readily available elsewhere, but in that book I know right where to find it quickly, because I've been referring to it there for years.

Apart from that, the oldest computer-related book that I use with any frequency, in any capacity, is my K&R2 (1988), which is exactly the right size and shape to support a mouse pad, so I use it for that any time I need to use a mouse elsewhere than on a desk. At one time I tried to use it in a fashion more usual for a book, but I found it rather lacking in that regard, simultaneously verbose (in explaining things every programmer already knows, regardless of linguistic background) and yet FAR too terse (in explaining the language it's supposed to be documenting). I think the lack of a decent book is one of the main reasons I never learned to make myself like or use C. (Another is that the language is inherently rather low-level, and I tend to want to solve higher-level problems. However, that can't be the whole deal, because, with a good professor and a decent book, I had no trouble picking up and enjoying 8086 assembly language, which is also fairly low-level.)

I've also got two volumes of Knuth on my shelf (the most recent date on the first volume is 1973), but I can't speak for its usefulness, because I never got around to reading it. I wanted to learn C first, _then_ read Knuth, and the first project never got done, so I never got around to reading Knuth. Similarly, the compilers book with the dragon on the cover is sitting around here someplace; I picked it up (used) around the same time that I picked up Knuth, expecting to read it after I learned C, which never happened.

The most useful computer-related book I've got is the (teal) camel, but that's not very old.

Sanity? Oh, yeah, I've got all kinds of sanity. In fact, I've developed whole new kinds of sanity. Why, I've got so much sanity it's driving me crazy.
  • Comment on Re: YAC (Yet Another Challenge): Oldest Useful Computer Text

Replies are listed 'Best First'.
Re^2: YAC (Yet Another Challenge): Oldest Useful Computer Text
by roboticus (Chancellor) on Apr 14, 2006 at 13:46 UTC
    jonadab:

    WRT K&R: I find that odd. I've got the first version, and always recommend it to my friends when asked how to learn C. I went through it and did all the examples, and felt I had really learned C.

    I'm always amused at the 'fat books' in the bookstores, and keep wishing for books on other languages that resemble the original K&R. (Of course, another thing that amuses me is that I find Perl *much harder* than C. I understand the rules in C, but am frequently surprised by things in Perl--I find myself much more in the "cut and try" mode when programming.)

    Of course, it's one of those "diff'rent strokes" sorta deals. Different people need things explained in different ways to get the best effect.

    Now, to keep my response somewhat "on topic", here's my list o' books:

  • "The C Programming Language" Kernighan & Ritchie, 1978. Terse, concise, recommended
  • "Data Structures and Algorithms" Aho, Hopcroft & Ullman, 1983. A nice survey of the fundamentals
  • "Computer Graphics, A programming approach" Harrington, 1983. Not a great book, but I like it. Nice refresher of stuff you should already know, if you do graphics programming.
  • "An Introduction to Data Structures with Applications" Tremblay & Sorenson, 1976.Uh, I used this in my classes. Amusing, but I wouldn't buy it again if I lost it.
  • "Computer Approaches to Mathematical Problems" Nievergelt, Farrar, Reingold, 1974. This is the second computer book I got, and the one I learned the most from. I don't know if it's a good one or not, but I didn't have much choice back then!
  • The dragon book (A compiler design book), ?Aho, Hopcroft? 19xx, This one is still on loan to a friend (Hey, Tim! 10 years is long enough, bring it back!) and is very good for compiler internals.

    --roboticus

[reply]

      I'm aware that the K&R is consistently well-recommended. That's why I bought it, after all. And it does compare favourably to books like "Teach Yourself Visual Basic in 21 Days". I have a tendency though to compare books in any given category with the really _good_ books I had read previously in that category -- fantasy books, for instance, tend to get compared to LOTR or to the Dragonbone Chair series, and computer language texts inevitably get compared to the Inform Designer's Manual and the camel book. (Yes, I'd read the camel book before I picked up K&R. Maybe that was part of the problem.)

      As far as Perl being harder than C, I think that depends very much on your linguistic background. I started with BASIC, and by the time I got to Perl I'd been through a number of other languages: Pascal (which revolutionized the way I wrote BASIC code), Fortran, COBOL (which I disliked), 8086 Assembler, Inform, Visual Basic (which is terrible as a programming language but terribly useful as a macro toolkit), Lingo (which I hated), QBasic, sundry batch and shell languages, and Emacs Lisp. Perl lends itself very well to the sort of multiparadigmatic approach that my linguistic background favoured, and, in particular, is useable as a drop-in replacement for QBasic.

      It may also be relevant that most of the programming I had ever done up to that point (except in Inform, which is rather specialized) involved text munging of one sort or another. The lack of a useable native string datatype in C is a real bummer for a new programmer picking up the language and wanting to do a lot of text handling.

      However, the most difficult thing about C, in terms of learning it, is the way it names functions. It's like the language designer tossed a ball of yarn over his keyboard and let whatever keys his kitten pushed be the name of the function he was writing. Combine this with the fact that there are *hundreds* of function names you have to know just to get the most basic of things done, and that the index only lists them by their alphabetically obscure names, not by what they actually do, and it's very overwhelming for a neophyte. In Perl you can do practically everything with about twenty keywords and a couple dozen operators. Yeah, there are additional functions with weird names (most of which are named for their C counterparts), but you practically never need any of them (sprintf is the only one of them I use with any frequency). The reference sections of the camel book (section 3, i.e., the command reference, and everything that follows) are useful later, but initially the beginning Perl programmer doesn't even need them; the information in sections 1-2 is enough to write working code that does practically anything. In short, I blame a large part of my Perl addiction on the quality of the camel book.

[reply]
        jonadab:

        Yep--that explains it! You moved into the higher-level languages sooner than I did. My progression was more like: BASIC, Z-80 ASM, 8051 ASM, C, FORTRAN, COBOL, x86 ASM, C++, yadda yadda Perl. Mostly, I started banging hardware (Electrical Engineering major) and drifted over to the softer side...

        Didn't really notice the fugly function names in C, as mostly I was ignoring them!

        It's like the editing holy wars: When your fingers are programmed to like vi/emacs/WordStar/etc., it "feels natural" and you wonder why all those in the other camps are "just so stubborn and wrong!" And, of course, vice versa!

        --roboticus (still wanting to find someone to pay him to learn Lisp!)

[reply]

In Section Meditations