I got through the first four chapters of PAIP yesterday and today. It's good so far. I had reservations about spending $80 on a book, but it's 950 pages and almost all of it is good stuff, from what I can see at a glance. Little space is wasted on introduction material or tutorials for people who know nothing about programming. He dives right into the good stuff in chapter four.

Already I've picked up a few nice bits of info, interesting standard functions / macros like TRACE which is good for debugging. And SUBLIS which takes a list of (key . value) sublists and replaces all the keys with all the values, in some other list. Common Lisp is such a freaking huge language, in terms of its standard library of functions. Good thing or bad thing? It may be a bad thing if not for the fact that you load Lisp once and it persists forever.

Norvig makes an interesting point about the REPL. What do most programs need to do? Take input from the user, do something with it, and give output back to the user.

To get input, your program can read from command-line args, or prompt to STDIN, or take it out of text fields in a QT app, or read it from a config file. But it's generally always strings. So you get some strings, and then what? You have to figure out what the strings say, and either turn the strings into something usable or use the strings to figure out what action to perform. So you may have a dedicated library to parse command-line args and a dispatch table to map them to function calls. Or you may match the strings against a regex and depending what the strings look like, turn them into your language's representation of an integer or float using some "parseInt" or "parseFloat" functions. Or if your strings are XML, you may parse them into some big funky XML structure, then access bits of that structure to figure out what to do.

In Lisp on the other hand, you happen already to have a powerful reader/parser at your disposal: the REPL itself. It already knows how to read string representations of lists, numbers, pathnames, and many other things, and it can turn them into Lisp objects for you with no effort on your part. If you were using Ruby or Perl, short of evil eval, you wouldn't get anything close to that capability in your program.

What's more, the REPL knows how to read string representations of Lisp code (new functions and function calls etc.), and evaluate the code and end up with Lisp objects. It would be like if you wrote a C program which prompted you for input, and the input you gave could be a string representing a new C program that when run would produce a string that contained your input (or produce in-memory C structures your C program could use). So the main program would call GCC and compile and run your input to get results and use those results as its final input. Except that still wouldn't be nearly as powerful as what Lisp is doing.

So if you can figure out how to shape your input into a form that the Lisp reader can read, you're set. And it so happens sexps are a great representation for a great many things. Maybe this is part of why Lispers seem to worship the REPL and shun compiling their apps into command-line, standalone executables? Maybe this is part of what's meant by the oft-quoted-to-death Greenspun's 10th Rule?

Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

Much more PAIP to follow. It should be enjoyable. There's nothing like a good book.

I got K&R (the ANSI C version) as one of the going-away presents from my current / last job, and I just finished reading it.

A lot of what's in the book is sort of review for me now but there were some things I'd never seen before. For example in the book they like to put function declarations inside other functions instead of globally at the top of the file. I never even thought to do that, for whatever reason. I also was unfamiliar with some of the more obscure corners of the C language, like register variables. Apparently the book was just written when ANSI was becoming / had become standard, so it's also fun to get a small glimpse at how things were before that. (They looked to be a mess.)

It's definitely the kind of book I wish I'd have had back in high school when I was just learning to program. For example the very straightforward explanation of how file handles work in Unix systems is nice and clear and is one of those things that I was wondering about for years in my youth: How is it that I can access stdout, stdin and stderr without doing anything? Where are those handles coming from? They seemed to be there like magic, and I never knew if it was always safe to assume that I'd have those available in every programming language I used on every OS I tried, or what. Likewise, I remember in the vast majority of programs I wrote in high school, I would trip up over I/O buffering. K&R explains that really well also.

Things that everyone "just knows" and assume that you also know are the biggest pitfall in learning computers, to me. Unix / Linux seems chock-full of that kind of crap. How do you know to try --help or man to figure out how to use a command? How do you know that ~ means "home directory"? How do you know that you start X via startx? If you don't know those things, short of asking someone else, it's very hard to discover how to do them. For people who know how to do it, it's such common knowledge that no one bothers to write it down. It's a huge leap that people have to make when first learning Linux or programming in general. A book like K&R is great because it gives you a starting point, and they explain pretty much everything. "Comprehensive" is probably the word I'm looking for.

In any case, as a rule, I detest low-level programming, of the "bit-twiddling" form. But there's obviously a need to know how to do it at times, and I think if I was more in the practice of falling back to C or other low-level languages when the problem at hand demanded it, I would probably be a better programmer. So I'm glad to try to learn more of it.