I had the same impression when it first came out and I dipped into it in the bookstore a couple times: it looked like a good treatment of a bunch of topics I'd

I had the same impression when it first came out and I dipped into it in the bookstore a couple times: it looked like a good treatment of a bunch of topics I'd mostly already been introduced to. This misses what I found most valuable when I did get around to it. There's another thread up on HN right now, "Nobody's just reading your code". Back then I read a lot of code from books, and read more actively by treating it like a reviewer: how could this code be clearer or otherwise better, how else might you do it? Most of the time, in many other books, you wouldn't get far before seeing some clear improvement. In PAIP this basically never happened. Often enough I would think of something, but if you worked it out in detail there was some less-obvious reason the code was the way it was. At one point I spotted a bug, and he wrote back that it'd been a year since the last bug report, and he'd started to hope there weren't any more. All the code in the book is pretty short, and it's not really "production code", but it's enough to be an education in craftsmanship at every level. I found that more interesting than the object-level topics, though they're worth learning about too. Nowadays if you prefer Python you can get a similar experience at https://github.com/norvig/pytudes#pytudes-index-of-jupyter-ipython-notebooks https://github.com/norvig/pytudes#pytudes-index-of-jupyter-i... treating different examples. One more personal reaction I had to this book: feeling like here was someone else with some of the same values. (Only, you know, smarter.) Someone with a similar taste, who couldn't resist coming back to their code repeatedly well after it's "done". The work in the end looks pragmatic, but sort of an idealized pragmatism: you have to really want to produce your best work, to work that hard over it.