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.
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.
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:
- Review the constraints outlined at the beginning of each chapter.
- 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.
- Share anything I find interesting.
- 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:
- 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.
- 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.
- 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.
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.
|Good Old Times||A small amount of memory for shared state. No variable names.||Coming Soon...|
|Go Forth||Inspired by the Forth programming language. Stack-based programming.||Coming Soon...|
|PART II||BASIC STYLES|
|Monolithic||No abstractions or libraries (single massive function). Aka code diarrhea.||Coming Soon...|
|Cookbook||Standard procedural programming with shared state.||Coming Soon...|
|Pipeline||Functional programming with no shared state.||Coming Soon...|
|Code Golf||Inspired by APL. As short as possible.||Coming Soon...|
|PART III||FUNCTION COMPOSITION|
|Infinite Mirror||Solve via induction. Aka recursive style.||Coming Soon...|
|Kick Forward||Functional style with additional function parameter (run this next). Aka continuation passing style.||Coming Soon...|
|The One||The M word... Monads.||Coming Soon...|
|PART IV||OBJECTS AND OBJECT INTERACTION|
|Things||Mainstream object-oriented style.||Coming Soon...|
|Letterbox||Smalltalk's original intention of object-oriented programming. Aka dispatching or message passing style.||Coming Soon...|
|Closed Map||Everything is mapped from keys to values (ranging from simple data to complex functions).||Coming Soon...|
|Abstract Things||Object-oriented programming with an emphasis on interfaces and other abstractions.||Coming Soon...|
|Hollywood||Callback style. Aka inversion of control.||Coming Soon...|
|Bulletin Board||Publish and subscribe.||Coming Soon...|
|PART V||REFLECTION AND METAPROGRAMMING|
|Introspective||A program knows things about itself, but cannot change itself.||Coming Soon...|
|Reflective||A program knows things about itself and can change itself at runtime.||Coming Soon...|
|Aspects||Allows behaviour injection before and after designated points, but does not modify existing code. Aka aspect-oriented programming.||Coming Soon...|
|Plugins||Allows open-ended systems to be modified after the fact via dependency injection.||Coming Soon...|
|Constructivist||Defensive coding with argument sanity checks. Arguments are modified to something acceptable.||Coming Soon...|
|Tantrum||Defensive coding that rejects bad arguments.||Coming Soon...|
|Passive Agressive||Exception handling at the top level.||Coming Soon...|
|Declared Intentions||Type system enforcement.||Coming Soon...|
|Quarantine||I/O Monad where functions can have no side effects (including I/O).||Coming Soon...|
|PART VII||DATA CENTRIC|
|Persistent Tables||Data storage and query. Aka relational databases.||Coming Soon...|
|Spreadsheet||Columns of data and formulas. Think Excel.||Coming Soon...|
|Lazy Rivers||Dataflow through streams.||Coming Soon...|
|Actors||Similar to letterbox style, but each object has its own thread.||Coming Soon...|
|Dataspaces||Concurrent and distributed systems using shared-memory.||Coming Soon...|
|Map Reduce||Split data into chunks, process in parallel and aggregate serially.||Coming Soon...|
|Double Map Reduce||Split data into chunks, process in parallel and aggregate in parallel.||Coming Soon...|
|Trinity||Model, View, Controller (MVC).||Coming Soon...|
|Restful||Synchronous request-response between server and client. Statelessness communication.||Coming Soon...|