I skimmed over a lot of the performance section since it seemed focused on low level C code and I try to avoid the sorts of situations where I would need to implement my own strstr() just to create a spam filter. This was another example of the text being dated.

Authors suggest saving exceptions for "truly exceptional" situations and don't think failing to open a file qualifies. There are two problems with this position: Failing to raise an exception means there are two error reporting channels and low-level code would have to check for all error situations. Moving all error reporting to exceptions means that low-level code is more streamlined because it doesn't have to consider error handling unless it can work around the problem (creating a missing file, for example).

Maybe the advice is based on bad exception support in Java? Or maybe their selected example is just not good. Searching for a substring may have been a better choice for an example.

Ch. 3 talks about Markov chains and generating text based on looking at an input set of prose. It reminds me of some code I wrote in '98 (in Python) to find phrases in a Framemaker file that looked like they might be worth adding to the index. Maybe I should recreate that stuff for Sphinx.

Chapter 2 has a good discussion of a simple quicksort implementation. On the other hand, does anyone still need to write their own sort functions? Do we really not have any other algorithms that are complex enough to be interesting, common enough to be worth reading about, and understood well enough that we can analyze them?

Programmers' endless creative energy is sometimes used to write the most concise code possible, or to find clever ways to achieve a result. Sometimes these skills are misapplied, though, since the goal is to write clean code, not clever code.

Ch. 1 is a pretty good summary of code style issues and recommendations.

This book is about the practice of programming -- how to write programs for real.

This book was published in 1999, and feeling a little dated so far. They use a lot of C, which may be more prone to some of the problems they warn against than other languages (esp. with style and expression side-effects).

It still has some value, though, so I'll keep reading.

I was a little put off by the flowery language and the fact that the author inserted herself into the story in a few places. There was also not as much information about the actual math as I had hoped. Someone who didn't already understand the theories may not have been the target audience, and I don't think they would have understood the significance of the contributions by Gödel and Turing. My review: Meh.

I'll never look at a chain restaurant menu the same way again.