A couple of weeks ago, I mentioned Writing Interpreters in Go, a book that teaches you to write an interpreters for the Monkey programming language. If you write software for a living, you should study this book. This is a software development book more than an interpreters book that has much to teach.
An overview of the book
Writing Interpreters in Go is incredibly well written. The structure is sound, with medium-sized chapters, each one of them focusing on one major task of an interpreter:
Lexing, reading a program as a string and making sense of each character to produce tokens. For instance: “if the current character, than all numbers up to the next whitespace is an integer”;
Parsing, where you combine tokens into an abstract syntax tree (the famous AST)
Evaluating, where you use the host language (in this case, Go) to convert a “Infix Plus operation a+b” from the AST into an actual instruction
a+b.
There are also chapters on extending the language from the initial implementation and on defining macros (this is really advanced stuff).
Differences between programming books and software development books
I’m at a stage in my carrer that I do not need to programming books, I need software development books. I consider the Go syntax actually quite simple, and appraise the author Thorsten Ball for not wasting time on that. He focuses on the much important issues of program organization, like creating separate modules for each major task. He create modules for the business logic, goes one level up to define a loop that reads input and applies that logic (parametrizing the I/O), and then create a main module to present this loop to the screen.
I also like how he defines tests very carefully, and is not afraid of testing edge cases. Is it just me, or that are too many testing tutorials with assert 1 + 1 == 2?
Key takeaways from the book
When thinking about a concept, start by creating small data structures, like structs, enums or classes. Codify in the program what’s on your head;
Write tests to define what you want from those data structures, and use the same inputs as the user. If your program takes a filename as an input, then the test should get the filename as an input. This tells you how hard is to actually use your program;
Don’t be afraid of going to the old-fashioned literature of papers and books. The major algorithm from Writing Interpreters in Go, a modern book about a modern language, comes from a paper from the 70s.
Have you read this book? What do you think?