(Cross-posted at Across Moon River)

I was eyeing Exercises in Programming Style (EPS) for a while, but I wasn’t sure if I wanted to get it in hardcopy or ebook format. I took a class and did some research with the author, Crista Lopes, when I was a grad student so getting a hardcopy signed would have been pretty neat. I registered for an agile conference at my alma mater and that led to my decision to purchase the hardcopy, but turns out I’m not being allowed to go. :( With the book in my possession regardless, I read through it.

I quickly found that it’s not a book that you read through once, but a text to revisit often. This entry is about my first read through and I hopefully will read through it again and write another entry, perhaps with new insights. I think my initial read was more of a surface level exposure to concepts and revisiting the book later, perhaps doing some of the exercises or just reading the Python code instead of glancing through it, will ingrain or connect the theory to practice.

EPS is not a book meant for beginning programmers. It is not a book meant for people who are coding because that is what they do and they somehow just do it well. It is meant for programmers who want to expand their view of what other “styles” of programming exists outside of what they are familiar with in their daily work (i.e., add tools to their toolset) and/or to understand the history of how programming has evolved with advances in hardware.

There is a well-known software patterns book by the Gang of Four. While somewhat similar, EPS should not be confused by that book. EPS is not about practical patterns that have emerged from solving problems and used towards efforts to write “clean code” or provide a common language for developers to refer to, but about styles that have emerged from writing code under certain constraints, whether they are self-imposed or from external sources.

The book has 33 short chapters, one for each style. Each chapter is split into at least two main sections – the code and commentary on the code. If applicable, there are historical notes and/or general examples of uses in production systems. The rest of the chapter contains a glossary, a bibliography, and some exercises. There is also a preface, which sets up how the project came to be and its inspiration from literature, and a prologue, which covers Python, the language of choice for the example code. I recommend reading the preface and the prologue before starting.

Although the book looks deceptively small, given I was paying ~$40 for the hardcopy, the print is small and I feel like it is an onion with many layers that require multiple readings and playing with the code to truly appreciate the solutions/styles that emerged when given certain constraints. One example is a memory constraint in the first chapter, that is not as prevalent today, but as we begin to work with Big Data, we are essentially dealing with a memory constraint but on a much larger scale. There is no way to load 1TB of data into 8GB of RAM.

I thought the flow was kind of interesting as looking at the first chapter vs. the last chapter, there is a style that was used in the early days of computing (though we are seemingly going full-circle as I said above with Big Data) to a style that is commonly used today in our web-centric world (REST). I want to say it has a chronological progression, but I also think some of these styles developed in parallel as there were different sets of constraints for different systems.

Another way to look at the flow is the larger sections that each chapter is grouped under. The first chapter is under the heading of “Historical” and the last chapter is under the heading of “Interactivity.” In between, there are sections on “Basic Styles,” “Object and Object Programming,” and “Data-Centric” to name a few.

There is no final, closing chapter. I think that inspires and encourages an ongoing journey for the serious programmer.