Exercises in Programming Style

I’m happy to announce that my book Exercises in Programming Style is now available for pre-order from Amazon, and that it will be shipping starting June 9! This is the book behind the talks I gave last year at StrangeLoop and GOTO. This is the story of how this book came to life, the inspirations behind it, and what the book is trying to do that is different from the hundreds of textbooks about programming.

Exercises in Programming Style was conceived in my head roughly two years ago, when I was teaching a new graduate course focusing on the analysis of programming languages. The goal of that course was (and still is) to take students on a tour of the main ideas that have emerged over the years in programming languages, and how those ideas relate to software development in practice. These courses are very hard to teach, pedagogically speaking. I’m not talking about teaching introductory programming, which has challenges of its own; I’m also not talking about teaching compilers or interpreters, topics that have well-known pedagogies around them for years; and I’m also not talking about teaching formal semantics or the mathematics of programming, which some books cover well. I’m talking about advanced topics in programming language design, which is very closely connected to advanced topics in programming in general. After all, some programming languages have very strong ideas for how programs themselves should be designed. After years of software development experience, and if we are lucky enough to work on a variety of projects using a variety of programming languages and technologies, we all acquire a large repertoire of techniques that we then instinctively apply (or avoid applying) to new projects; it would be nice to be able to teach those techniques to people who are just starting their professional careers, and to experienced professionals who have used only 1  or 2 technology stacks in their work.

We all know that practice and experience are what makes people excellent programmers and system builders, but somehow our training in Computer Science and Software Engineering tends to focus more on the theory of the art than on the art itself… Partially that is because we haven’t found the right formulas for teaching techniques without falling all the way to teaching particular technologies, which is always very limiting. Technologies (i.e. programming languages, libraries, frameworks) come and go; techniques find their way to new technologies over and over again. That’s what I’m trying to address with this book — how to teach techniques that have been around for many years and that can be found in many places at many scales.

Some Computer Science and Software Engineering programs offer courses covering design patterns. That’s the closest to what I had in mind for my course, but design patterns have two shortcomings: (1) Most design patterns that became popular with C++ and Java fall a bit short from what I think is important for students to learn these days. For example, the several uses of higher-order functions aren’t usually covered; approaches to deal with adversity are also not covered; etc. (2) More importantly, design patterns convey the idea, perhaps unintentionally, that it doesn’t matter what language you use, as long as you then apply those patterns. I don’t think that’s quite right. There’s a continuum between programming languages and design patterns, and the line between them is very fuzzy. Some programming languages provide features that subsume some design patterns. I was looking for a pedagogy that would make the difference between languages and patterns go away. Nevertheless, the many design patterns books were a stepping stone for mine. There was just something missing from them, pedagogically speaking, something I finally found 2 years ago elsewhere. The keyword is style, but with a very precise meaning that I borrowed from a group of French intellectuals.

I got the inspiration for Exercises in Programming Style from Queneau‘s Exercises in Style. I came across this book 2 years ago, and I was struck by how well a book like that could teach advanced programming while making differences between languages and patterns go away. As I learned more about Queneau, I was convinced that the approach followed by the Oulipo school is really spot on for programming, and that we might all benefit from it when explaining old and new things. By that school, style is a consequence of creating something under strict constraints. For example, try writing a story without using the letter ‘e’, or by using questions as the means to tell the story or some other interesting limitation. These are examples of constraints. By honoring different constraints we end up with completely different renditions of the same story. Constraints are what defines the styles in my book: a programming style is a list of constraints for how to write programs.

Similar to Queneau’s Exercises in Style,  Exercises in Programming Style starts with simple computational task (counting and sorting words in a file aka term frequency), and presents 33 different ways of coding it, according to different constraints. The task and the language are fixed; what changes is the way of dividing the problem and composing the pieces together. This way, people can focus on the variations regarding the expression of ideas instead of being distracted by language syntax, modeling notation or the algorithmic difficulties of implementing the task. Constraints can be of many natures; it doesn’t really matter, as long as they are constraints for how to write the code. The styles are illustrated with code (Python), most of them no more than 1-page long. The first exercise in each chapter asks to rewrite the program preserving the style but using another programming language. Sometimes that’s trivial, other times it’s not so trivial.

(33 different ways of coding term frequency?!? Yes, sometimes I suffer from OCD!)

Queneau was the inspiration, but his work resonated with lots of other things that I carry with me. I am a classically-trained musician. Therefore, I have been exposed to approaches to learning that are better suited for the performing arts. In that world, practice is everything. We practice flexibility, range and expression for hours on end. I am very fond of musical exercise books such as the Hanon exercises, collections of scales and arpeggios, the Piano Handbook, the Marchesi vocalises, and many others. These exercises, too, are constrained pieces with very specific objectives. They aren’t the music. But they help musicians master important techniques that allow them to ace the music during performance.

Programming is also a performing art: you have to deliver something that performs well under many different dimensions. Running code, especially one that evolves over time, is a long-lived performance by its writers!

Having students practice exercises in programming style, constrained and with specific objectives, will allow them to master those techniques in controlled settings. When the time comes to building real systems, I hope they will remember the many ways to divide the problems and assemble the pieces that they learn in this book. Experienced programmers may also find these exercises helpful, in the same way that professional musicians keep doing exercises throughout their lives.

In writing this book, I also wanted to convey the origin of the programming techniques that are covered. Wikipedia is, to a large extent, useless when it comes to tracking the history of programming techniques; the articles tend to focus on explaining what the techniques are, almost like manuals, and fall short on giving solid historical perspectives. So while writing the book, I spent a considerable amount of time tracking down original articles that I then refer the reader to. One side effect of that research was an article I posted a couple of months ago.

The code supporting the book is all available in github. In the next few weeks I will be posting some chapters of the book.