Exercises in Programming Style | Henrik Warne's blog
I have read quite a lot of books on programming, but this book is unique among them. I really like the approach of showcasing various programming styles and paradigms by implementing the same program in different ways. First, there is a concrete program to look at for each case, instead of just a verbal description. Second, seeing all the programs next to each other highlights the differences in a very accessible way.
At work we use Python, so all of us already knew Python when reading the book. It was quite convenient to already be familiar with the language used, but I think the book works well even if you don't know Python. There are a few quirks, for example with classes in Python, but the author explains those when needed. The only time Python was a problem was when showing how types protect against errors in the Adversity section.
When it came to understanding the programs, there was always a very good section called Commentary that explained in detail how each program worked. For the most part though, I preferred to just start reading the code and see if I understood how it worked. Usually this was enough, but sometimes I missed not having an IDE for searching for usages etc. I could have done that though, because all of the programs are available on GitHub.
For each style there were references and historical notes. These were quite good and interesting. In particular it was surprising that there were so many references to papers and books from the 50s and 60s. There were also a lot of references to Smalltalk, and to Dijkstra.
Before reading the book, I decided to implement my own version of the term frequency program. This gave me an slightly better understanding of what is needed to solve the problem. Mostly though, it was for the fun of seeing which style my solution was written in. The best match turned out to be Pipeline in Basic Styles. Also, when testing my solution I noticed that the Pride and Prejudice sample input the author is using also includes a few Project Gutenberg sentences in addition to the book text. I found this slightly disappointing.
My only criticism of the book is the naming of the styles. Naming is famously hard, but also very important, because the names help you remember the styles better and makes discussing them easier. In many cases, there are already establish names for the styles, but instead of using them, the author came up with her own. For example: Trinity instead of MVC, Things instead of Objects, Hollywood instead of Callbacks, Bulletin Board instead of Pub/Sub and Kick Forward instead of Continuation-passing. Those names are OK, but it is much better to stick to the industry standard ones.
Read full article from Exercises in Programming Style | Henrik Warne's blog