Exercises in Programming Style

Back in the 1940s, the French writer Raymond Queneau wrote an interesting book with the title Exercises in Style featuring 99 renditions of the exact same story, each written in a different style.  It is a master piece of writing technique, as it illustrates the many different ways a story can be told.  The story being fairly trivial and always the same, the book shines the spotlight on form, rather than on content.  As such, the book is of great value to all those interested in the technical aspects of the Art of Writing, and in how the decisions we make in telling a story affect the perception of that story.

Over the years, as an instructor of many programming-intensive courses, ISR professor Crista Lopes noticed that many students have a hard time understanding the many different ways of writing programs and of designing systems, in general.  They have been trained in one, at most two, programming languages, so they understand only the styles that are encouraged by those languages.  It’s not their fault.  Looking at the history of programming languages, and the lack of pedagogical material on style in most CS programs, one hardly gets exposed to the issue until after an enormous amount of experience is accumulated.  Even then, style is seen as this intangible property of programs that remains elusive to explain to others – and over which many technical arguments ensue. 

In order to give programming styles the proper due, and inspired by Queneau, Lopes decided to embark on the project of writing the exact same computational task in as many styles as she has come across over the years.  This project involves two artifacts: a collection of code examples currently hosted in github (https://github.com/crista/exercises-in-programming-style), and a textbook that explains 32 of those code examples line by line.  The collection is public, and several other people have already contributed to it – among others, there is a contribution from Peter Norvig, Director of Research at Google!  The textbook targets courses on advanced programming / Software Engineering, and will be available in Spring 2014.

So what is style?  In Queneau’s circle of intellectuals, style was nothing but the consequence of creating under constraints, often based on mathematical concepts such as permutations or lipograms.  These constraints were used as a means to create something new and intellectually interesting besides the story itself.  This idea of associating style with constraints, however, precedes Queneau by several centuries; in all corners of the Arts, style – operationally defined by a set of constraints of what to do and what not to do – has always played a central role in creativity.

In this project, too, programming style is what results from writing programs under a set of constraints.  Constraints can come from external sources or they can be self-imposed; they can capture true challenges of the environment or they can be artificial; they can come from past experiences and measurable data or they can come from personal preferences.  Independent of their origin nature, constraints are the seeds of style. By honoring different constraints, we can write a variety of programs that are virtually identical in terms of what they do, maybe even have the exact same output for a given input, but that are radically different in terms of how they do it.  An advanced programmer needs not just to be able to write correct programs; he/she will find throughout their careers.

Another goal is to make the often forgotten points that: (1) style matters; (2) programming languages are primarily instruments for suggesting/enforcing programming styles; and (3) the enforcement done by programming languages may be strong or weak, therefore one should not rely solely on the programming language for the purposes of establishing style(s).

A third goal is to catalog the various different ways by which entire software systems can be engineered.  What can a simple 100-line program teach us about engineering Facebook, for example?  Well, a lot.  Because of the fractal nature of software, the various ways by which we can decompose a small computational task into conceptual units are all similar to the various ways we can decompose large systems into components.  At the core, these are the ways of sub-dividing computational problems into smaller computational problems, independent of the size of the original problem.  In software engineering research, decomposition at the system level is known as “software architecture,” and the styles are known as “architectural styles.”  In that light, this book is a catalog of several architectural styles.  The fact that it uses a trivial computational task is, in Lopes’ view, an advantage over using production systems, from a pedagogical point of view.

Software is not just an Art; there are utility functions attached to software systems.  In her book Lopes tries to stand clear of judgments of good and bad.  Those judgments depend heavily on the context of each project.  These exercises in programming style, similarly to Queneau’s exercises in style, are exactly that: exercises.  They are the arpeggios and scales of software, they aren’t the music.  A piece of real software usually employs a variety of styles for the different parts of the system. All these styles can be mixed and matched, creating hybrids that are interesting in themselves.