- The Anatomy of a Compiler, by John A. N. Lee, Reinhold Computer Science Series, New York, NY, 1967, LCN 67-29207
--hsm
"Never try to teach a pig to sing...it wastes your time and it annoys the pig."On my shelf right now are:
- The C Programming Language by Kernighan & Ritchie, 1978.
- Compilers: Principles, Techniques, & Tools (aka, the Dragon Book) by Aho, Sethi & Ullman. 1986
Another wonderful classic that I've checked out of the library many times but haven't bought for myself (yet):
- Computers & Intractability: A Guide to the Theory of NP-Completeness by Garey & Johnson, 1979.
Also not on my bookshelf, but this post reminded me of something amusing I remember seeing. One of the algorithms professors at my university lists
- The Cat in the Hat Comes Back by Dr. Suess, 1958.
as a recommended textbook for his algorithms class, describing it as: "One of the best books ever written about recursion. And toilets." ;)
blokhead
- The oldest is a '78 copyrighted edition of K&R.
Sits on my desk and gets used most weeks.
- Fundamentals of Interactive Computer Graphics. Foley & Van Dam. 1984
Lives in the bookcase behind me, and only gets opened occasionally, but it's still the best graphics algorithmm book around.
These aren't exactly programming books, but I'd nominate "Through the Looking Glass" and "Alice's Adventures in Wonderland" (Charles Dodgson, a/k/a Lewis Carroll, various editions) as two great books about logic.
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.
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:
--roboticus
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.
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!)
You moved into the higher-level languages sooner than I did. My progression was more like: BASIC, Z-80 ASM, 8051 ASM, C
Maybe it depends too on what you did with BASIC. I did a lot of fairly high-level stuff with BASIC: string-handling, graphics, character-based GUI-like stuff (pulldown menus, repositionable overlapping windows, ...), and the like. I did also do some pixel graphics and PC speaker sound, but although the flow control was fairly primitive in the variant of BASIC I used (mostly consisting of IF ... GOTO and GOSUB), it was in most other respects a rather higher-level language than C. Critically, BASIC has dynamic-length strings, which I for years considered to be the single most important data structure for a general-purpose language to have. (These days I tend to think hashes are just as important, but that's my Perl addiction talking.) If a language doesn't have dynamic-length strings, you usually end up spending 75% of your time working around the lack of them.
The only exception I have ever encountered to this is Inform. Inform not only doesn't have dynamic-length strings, it doesn't have dynamic strings: the characters that make up all strings are determined when you write the code, not at runtime. I'd been happily programming in the language for a couple of years before I even noticed this, but the reason has to do with the peculiar combination of Inform's fantastically good object model and paradigm with its special problem space. Because of these special considerations, an Inform programmer who wants a string in a particular place to be dynamic can just substitute a routine that dynamically decides (based on the current states of various objects and their properties) what to print and prints it; because of the way the object model and paradigm work, this is the natural way to do things. (I know, it sounds weird, but given the problem space and paradigm of the language, it's very natural. The reason it was done this way is because of the virtual machine that Inform targets, which was designed for extreme portability. Strings and routines are at the end of the compiled program, in the part that can be accessed directly from read-only media if necessary.)
It's like the editing holy wars: When your fingers are programmed to like vi/emacs/WordStar/etc., it "feels natural"
I don't use Emacs for the key bindings. Frankly, I don't want anything to do with the default keybindings in Emacs. I use Emacs for its copious functionality, but I've got the keystrokes I use with any frequency rebound to something sane. I am occasionally forced to use an installation of Emacs that doesn't have my custom lisp installed, so that it's got the default keybindings, and it drives me nuts. I can generally only take that for an hour or two, and then I have to install my elisp stuff and set it up for _comfortable_ editing.
--roboticus (still wanting to find someone to pay him to learn Lisp!)
Don't wait. Shoehorn it into your Copious Free Time. It only takes a couple dozen hours to become conversant in Emacs lisp, and it's probably the best time investment I've ever made in a computer technology, or maybe the second-best. (The time I spent initially learning Perl is the other contender.)
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.
Maybe it depends too on what you did with BASIC.
Heh... I bought the first (?only?) TRS-80 in my state with Level II BASIC and only 4K of RAM. I was mostly an electronics geek back then, so mostly did circuit simulation-type stuff. Due to lack of cash and RAM, I had to move into assembler quickly. (3284 bytes free of RAM isn't a lot in BASIC, but it's a vast open field in ASM!).
...but although the flow control was fairly primitive in the variant of BASIC I used (mostly consisting of IF ... GOTO and GOSUB), it was in most other respects a rather higher-level language than C.
Learning C after assembly, I never really considered it a high level language, but more another version of ASM with nicer syntax and easier to work with. (I would frequently compile to ASM to help me debug my code, so I could see if what I thought I said agreed with what the compiler thought I said.)
Critically, BASIC has dynamic-length strings, which I for years considered to be the single most important data structure...I tend to think hashes are just as important...
I wholeheartedly agree with that! For me, the big attraction to Perl is hashes and regex. Any time the problem at hand feels like it wants one of those, I start vim and enter "#!/usr/bin/perl -w". I need to learn more list-based tricks (Schwartzian transform, etc.) to enlarge my bag o' tricks...
I don't use Emacs for the key bindings.I always thought that people who used Emacs for all had extra pinky fingers or were concert pianists or something! </joke> (Sorry! But you gotta admit that after CP/M's ED editor, VI is somewhat of a natural!)
Don't wait (to learn Lisp). Shoehorn it into your Copious Free Time. It only takes a couple dozen hours to become conversant in Emacs lisp, and it's probably the best time investment I've ever madeI've actually started a couple of times, but have a lack of that substance you refer to as "Copious Free Time". I've heard many people whose opinion I respect tell me that learning Lisp is very worth my while, and I believe it. The references to functional programming have really piqued my interest. However, I've been coding long enough that learning a new language isn't interesting enough--fun, but it's a little too much like work. I turn on the computer, crack open the Lisp dox and a bash shell, type a couple of lines of code, and then start wondering what's on Slashdot/Groklaw/PerlMonks/...
Now, when I have free time, I like to dabble in Metalworking and work on a steam engine or something else that I can plunk down on a table and have people be able to *see* what I do.
--roboticus
I was mostly an electronics geek back then, so mostly did circuit simulation-type stuff.
Yep, that fits. Your ability to grok C is directly tied in with this background. I was always more of a software guy.
Learning C after assembly, I never really considered it a high level language, but more another version of ASM with nicer syntax and easier to work with.
This is similar to my eventual accessment, which finally drove me away from further attempts to master the language. One difference is that I actually think 8086 assembly has a cleaner and more straightforward grammar, the cheif advantage of C being that it is less dependent on a specific architecture.
For me, the big attraction to Perl is hashes and regex.
These are both very nice features. I'd picked up regular expressions with elisp, but hashes are rather more convenient, for a lot of tasks, than alists or similar lisp data structures, and Perl's regular expressions are also rather better than lisp's, for several reasons. (Among these reasons: there are dedicated quoting structures for regexen, which makes the syntax much nicer, as you don't have to do nearly so much double-backslashing; convenient in-place substitutions with s///; modifiers such as /i and the like; capturing is more convenient in terms of syntax.) Other things I like about Perl include the dynamic typing (which is superficially similar to Inform's typing system, which I quite like), the equal standing of multiple paradigms (procedural, functional, object-oriented -- allowing any given problem to be solved in a natural way), the terseness (which allows entire functions to fit on the screen in one half of a vertically-divided editor window, greatly contributing to maintainability), and, above all else, the quality of the 2nd edition camel book, which is easily the second-best computer language book I've ever read (after the Inform Designer's Manual, which alone among all the computer books I've ever seen is deserving of serious critique on its literary merit).
I need to learn more list-based tricks (Schwartzian transform, etc.) to enlarge my bag o' tricks...
Perl is a good language for learning these things. Even though I came from a background of having previously programmed in elisp, it was Perl that really taught me to think that way. It was in Perl that I first really understood closures, and it was in Perl that I first really *fully* understood list transformations, and I am convinced that it will be in Perl6 that I finally grok continuations -- although I attempted to study Scheme for the express purpose of understanding continuations, I came away from Dybvig only halfway understanding them. But when I can see the examples in Perl, then I am convinced I will understand better.
Then again, maybe it's that way for me because I think in Perl. If you think in C still, maybe you should try implementing the Schwartzian Transform in C, to understand it. The syntax would be rather different, but I'm sure it could be done. I could do it in QBasic. It'd be a bit weird, but I could do it. For that matter I could do it in line-number basic, with GOSUB (i.e., without the benefit of functions that take arguments).
I always thought that people who used Emacs for all had extra pinky fingers or were concert pianists or something!
Now that you mention it, I do have an Avant Stellar keyboard and a customized layout, and I do have both ctrl and shift on home positions (right and left pinky, respectively). However, I think that would be worthwhile even if I didn't use Emacs, because I'm a heavy keyboard-shortcut user, irrespective of application. It's just faster and easier than dragging the mouse all over the desktop every time you want to do anything. And practically every application uses Ctrl and Shift combinations.
I've actually started a couple of times, but have a lack of that substance you refer to as "Copious Free Time". I've heard many people whose opinion I respect tell me that learning Lisp is very worth my while, and I believe it. The references to functional programming have really piqued my interest. However, I've been coding long enough that learning a new language isn't interesting enough--fun, but it's a little too much like work. I turn on the computer, crack open the Lisp dox and a bash shell, type a couple of lines of code, and then start wondering what's on Slashdot/Groklaw/PerlMonks/...
This is the problem I had when I tried to learn Haskell. I just couldn't get myself interested in it. I got further with Python, but kept running into how needlessly verbose everything was and how "forced" the object-oriented paradigm felt when applied to some of the problems I was working on and how much easier it would be in Perl. With PHP, I just couldn't stand the tone of the text I picked up. I already explained about C. So, now that you mention it, Perl is, so far, the last language I picked up, learned, and liked. On the other hand, most of the languages that I learned *before* Perl were ones that I discarded after a bit and went back to BASIC. I kept going back to BASIC, after learning Pascal, COBOL, Fortran, a little bit of C++ (not really enough to be useful), and so on. Setting aside Inform, which is not general-purpose enough to be used for the things I typically did with BASIC, it wasn't until elisp that I started doing things in another language that I formerly did with BASIC, and even then I continued using BASIC for other things until I became comfortable in Perl. So I think it's a matter of finding the right languages, the ones that are going to meet your need where you are at the time, do something that was awkward in the languages you'd been using, and thus take you to new and interesting places.
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.
The first edition of Programming Perl by Larry and merlyn. I sill use it's Functions chapter when perldoc is not available. I see that it's celebrating it's sweet sixteen this year (© 1990)! (that makes me feel old)
FWIW, I have a "Perl programming CD" I carry everywhere (well, it's now a USB flash disk, but that's no matter) with the downloadable version of the html version of perldoc -- it uses JS for it's search function, so even without a net connection, it's still very useful.
It also has a miniature CPAN on it with such things as CGI::Simple, my snippets and utility module collection, some useful scripts, and a working PXPerl (for when I have to work on a Win box that has no perl on it; I've not yet had that issue with a *NIX machine...).
A collection of thoughts and links from the minds of geeks
The Code that can be seen is not the true Code
I haven't found a problem yet that can't be solved by a well-placed trebuchet
I suppose my _oldest_ useful (and well-used) computing text would be my original John McCarthy's LISP 1.5 Programmer's Manual, circa 1962. I reread it (and parts of Patrick Winston's LISP (1 & 2)) just about every time I implement a new little language, because he and his students wrote the book on meta-programming.
UPDATE: b'damned, but I LOVE the Internet! LISP 1.5 Programmer's Manual is a scanned copy of the hand-typed version. Mine is only the first printed edition. :D
Don Wilde
"There's more than one level to any answer."
Update: I was a bit surprised to see jdporter's list date this as 1972, but sure enough that is shown in my copy as Fred Brooks' own copyright date. Evidently it took him 3 years to get a publisher interested. The 20th anniversary edition was published in 1995 - I guess 23rd anniversary didn't have the same ring to it ;-)
--
I'd like to be able to assign to an luser
These aren't all equally interesting...
- The Mythical Man-Month, 1972, Fred Brooks.
- Gödel, Escher, Bach, 1979, Douglas Hofstadter.
- Vol. 1 and Vol. 5 of the UNIX manuals (sections 1 and 5 of the man pages!), 1986, AT&T.
- (LISP 1.5 PRIMER (BY (CLARK WEISSMAN))), 1967. (PDF available)
- a FORTRAN book, 1973, Michael J. Merchant.
- a FORTRAN book, 1974, Boris Boguslavsky.
- a COBOL book, 1973, Martin L. Harris.
- a COBOL book, 1977, Shelly & Cashman.
- Computer Networks: A Tutorial, 1984, Abrams & Cotton.
- (Tutorial) Local Network Technology, 1985, William Stallings.
I also have a 1st edition K&R, which needs no further ado.
Not directly programming related, but if you're doing UI work, and tend to generate reports. (or if you have to deal with sales literature, or anything that deals with graphing)
- Huff, Darrell (1954). How to Lie with Statistics. (reissued in 1993).
The only other >20 yr old books I have on my shelf that might be worth reading are on indexing languages. They're written for library science folks, not comp sci, so the jargon and obsessive cross references takes a little getting used to:
- Soergel, Dagobert (1974). Indexing Languages and Thesauri: Construction and Maintenance.
- Soergel, Dagobert (1985). Organizing Information: Principles of Data Base and Retrieval Systems.
(I also have some really old database books, but I don't know that I'd recommend them ... and older langauges (PC LOGO, FORTRAN, but they're only useful if you're working in the language)
Update: for those not familiar with Huff's book, although the title sounds like its intent is to be deceptive, and can be used that way, it also make a number of suggestions about how to convey information that won't be misinterpreted, and things to look for that might suggest that the data is suspect
While it's not really a programming book, the oldest computer book I have is a technical reference for the IBM XT personal computer from 1983 (older than me). It's mostly a reference book concerned with hardware and hardware programming of the PC, with more tables than normal text. It has the full assembly listing of the ROM BIOS (except for the BASIC ROM), and lots of circuit diagrams of which I don't understand anything.
FOIL: FOIL On Incandescent Light - transparencies used on overhead projectors.
-QM
--
Quantum Mechanics: The dreams stuff is made of
We us a hardware clone (see below) of said machine to control the nuclear reactors and the associated boilers and valves at the Bruce "A" and Bruce "B" Power Generating Stations. They are opperated by Bruce Power.
Some parts have been replaced with more modern components. For example, the core memory has been replaced, but it still only has 32KW (64KB, 16 bit addressable) of RAM. We load binaries on the machine via a serial connection to a device pretending to be a paper tape reader to the Varian.
--hsm
"Never try to teach a pig to sing...it wastes your time and it annoys the pig."Why would it be? Do software and hardware designs go bad after a while?
If you're worried about the hardware itself going bad, that can happen to new hardware just as easily. Maybe even more so since they are much more complex. Redundancy and fault tolerance are key factors no matter which hardware is used.
"Fixing" it would involve rewritting entire bookshelves of assembler code (since assembler is machine specific). That includes completely redesigning the OS to take advantage of the extra memory and disk space a new machine would provide, and you'd have to do deep structural changes to all the applications to be able to run on this new OS.
It's politically difficult to tell people: "we're going to make changes to how we run our nuclear reactor" unless you have a very good reasons.
The Chernobyl disaster was only possible because some manager decided that it would be a good idea to let scientists do some experiments on a live nuclear reactor (and then let them disable multiple fail-safe systems, so that they were running without backups -- then they reacted badly to a lack of instrumentation). Sometimes, a healthy dose of "leave it alone" syndrome is a good thing; especially when mistakes can kill thousands of people.
--
Ytrew
The oldest computing/programming related books that I keep to hand and refer to occasionally are:
- "Cybernetics and Society", Wiener N., 1950.
- "The Mathematical Theory of Communication", Shannon C. & Weaver W., 1949
(although my copies of both are 90's reprints). Wiener in particular has some interesting discussion of the nature of feedback.
--------------------------------------------------------------
"If there is such a phenomenon as absolute evil, it consists in treating another human being as a thing."
John Brunner, "The Shockwave Rider".
Can you spare 2 minutes to help with my research? If so, please click here
Don Wilde
"There's more than one level to any answer."
The book that got me really interested in computers:
Structured Computer Organization by Andrew S. Tanenbaum, (maker also of minix, way back the starting point for Linus' Linux).
I don't have the book here, its probably somewhere late seventies.
There is a 5th edition by now (which I don't have).
my school library has a few fortran/cobol books from the 60s. i'll post those if i can find them.
(i'm the only one who's checked them out in 20 years, I don't think it'll be a problem :)