Re^2: YAC (Yet Another Challenge): Oldest Useful Computer Text

[roboticus]

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

[jonadab]

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.

[roboticus]

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!)

[jonadab]

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.)