Exercises In Programming Style – Introduction

A few months ago I had the good fortune of coming across a very interesting talk by Crista Lopes about Exercises in Programming Style recorded at the Joy of Coding conference. In this presentation she talked about how people tend to become frozen within a certain coding style influenced by the particular programming language(s) they use (often the first one that they did a “real” project in becomes a person’s reference point and biggest influence). I wholeheartedly agree. In my experience, many people, myself included, tend to get comfortable with a certain style of programming based on the idioms of the particular language they use most often. Essentially, if your main tool is a hammer, every problem looks like a nail.

She goes on to explain that as people become exposed to more languages and technologies throughout their career, they start to see that there are many different ways to approach a problem; different programming styles if you will. So how do people with this experience transfer this knowledge to younger generations of programmers just starting out? Her idea is to take a trivial task (just difficult enough to require real code) and impose explicit constraints to your program. This essentially emulates the various styles. As a side note, her inspiration for this format is quite interesting.

The Book

Recently she released a book containing 33 explicit, constraint-based programming styles. With each style, she uses Python to demonstrate the concepts, using the same task: Read in a text file (Pride and Prejudice book), read in a list of stop words, do a word frequency count and display the 25 top words (excluding any found in the stop words file).

Each style is accompanied with an explanation of the code, historical notes, further reading and some exercises to further explore the style. In addition, the code from the book has been posted on github.

The Plan

I just recently finished reading Crista’s book and thought it would be interesting to do a blog post about each style that was covered in the book.

As a side note, I will likely do an official review on her book too. Spoiler alert. I recommend it (and watching the talk I mentioned previously that she gave at the Joy of Coding conference).

As far as my blog posts go, my plan is to do the following for each style:

1. Review the constraints outlined at the beginning of each chapter.
2. Write my own version of the program (not necessarily a one-to-one translation of the Python code provided in the book), fulfilling the constraints. This will be done in three different programming languages.
3. Share anything I find interesting.
4. Most importantly, learn something new!

So why three languages you ask. Initially I had this grandiose idea to do each style in a plethora of programming paradigms such as procedural, object-oriented, functional etc., with a mix of dynamic and statically typed languages. However, this is a little ambitious and I’d like to see my wife and children sometime before next year. Instead I thought I’d do the following languages for the following reasons:

1. C# – It is a multi-paradigm language with an emphasis on object-oriented programming. C# has been my main (and favourite) language for many years. I also use it for many things in my day job. It’s part of the .Net framework, with which I am quite familiar.
2. F# – It is a multi-paradigm language with an emphasis on functional programming. F# is the language I’m currently learning (watch out C#, it is becoming my new favourite language). What better way to learn and explore a new language than to solve a problem multiple ways (some idiomatic and some not). And again, it is part of the .Net framework.
3. C/AL – This one I chose out of pure curiosity. It is a specialized 4GL programming language (based on Pascal) used for Dynamics NAV. I use it daily for my job. It also has access to the .Net framework (are you sensing a theme here?), but with some restrictions. Unfortunately there are many features that are missing at the language and compiler level (no access to .net delegates and no concept of lambdas or higher-order functions… boo-urns!), which may make some styles in the book seem impossible (or at least not very plausible without some major voodoo).

It should be interesting to see what styles are easier in each language due to their specific idioms. Often when a language doesn’t have an idiomatic way to handle certain constraints, you end up with a common design pattern as a (usually) proven template for a solution. Other times, you end up with some ugly monstrosity of code that nobody fully understands and is afraid to touch.

I encourage you to spread the word about this book and try the exercises for yourself. Too often do I see code written poorly that could be done much better if people only knew how to think of solutions in various ways.

The Styles

Here is a list of the styles in the book. I will update each style with a link as I blog about them over the coming weeks.

NOTE: Expand the table to show 50 entries to see them all at once.

Programming Styles