Heh. The books on the list would be the ones from which I learned new ways to think about programming. Most of them are now long out-of-date, as witness the discussion on "101 BASIC Games" going on elsewhere on Hacker News.

"101 Basic Games", edited by David Ahl and published by DEC. I learned to program by typing in the code from this book back in the late '70's.

"Write Your Own Programming Language Using C++", by Norman E. Smith. This is about writing a simple Forth interpreter. I used what I learned to write a simple Forth interpreter in C, which I then used as an embedded extension language in a couple of apps I was working on at the time. This was on a VAX, and rather before I'd ever heard of anything like TCL/TK.

"Tcl and the Tk Toolkit", by John Ousterhout, which (among other things) explained how an embedded extension language ought to work.

The O'Reilly X Windows books, and various O'Reilly books with animals on the cover. They were essential references, back in the day.

"The C++ FAQs", by I don't remember who. I never used C++ much; but this book was an excellent introduction to all of the pitfalls in the C++ of the day, and how to use C++ without shooting yourself in the foot--and an even better example of how to write for programmers. It was a big influence on how I later wrote programmer's documentation.

"Refactoring", by Martin Fowler. I've never followed the advice in this book slavishly, but it's tremendously affirming to read a new book encouraging you to do what you were doing already without having a name for it.

"Effective Java", by Joshua Bloch, which I spent a lot of time with about ten years ago; it helped me come to grips with Java and avoid a variety of foot-guns, much like "The C++ FAQs".

Various Lisp books; I don't like Lisp all that much, or Scheme either; but I come back to one or the other every few years and take another look, because I always learn something.

Various other texts on specific programming languages, as I experiment with them; "Learn You a Haskell for a Great Good" sticks out mostly because it has a memorable title.

And "Crafting Interpreters", which I've worked all the way through and then run with. Last month I implemented a simple Datalog implementation in a few days using the techniques from CI; I'll soon be integrating it into a much enhanced version of Nystrom's Lox.

Ask HN: Writing an Interpreter in Go or Crafting Interpreters?