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.
In reply to Re: YAC (Yet Another Challenge): Oldest Useful Computer Text
by jonadab
in thread YAC (Yet Another Challenge): Oldest Useful Computer Text
by hsmyers
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |