Collecting Code

As a child, I used to collect stamps. Looking back, this seems to be a strange hobby to me now. After all, what can you do with a collected stamp? Most of my stamps were used ones, so I could not even use them for sending letters.

These days I’d like to start a new collection. A collection of source code. I hope that collecting code will be more fulfilling and will stay longer with me than the hobby of collecting stamps. Why? Because code has more dimensions than stamps have. One obvious dimension of code is its functionality: What does it do? Another dimension is revealed by the question: How does it do, what it does? Yet another dimension is its beauty: When looking at the code, how easily can I see what it does? And if its functionality is complex, how easily can I see how it does what it does? A further and not the least interesting dimension is how easily I can use this collection of code in my everyday phlegmatic programming.

One problem with a collection of code is that code always exists in a certain ecosystem. It is written in a certain programming language. It uses libraries which are  only available for this programming language, or maybe only available for this programming language running on a certain platform, and only if the source code is compiled with a certain compiler. You could argue that programming languages and libraries and compilers also have some kind of representation as source code. Should the collection of code then strive to also contain this kind of second order source code?

What about the binaries that are produced from source code (like .exe files) or accompany source code (like .png files). What about the developer documentation that makes it simpler to understand what the source code does and how it does it? Should I care about including user documentation although it typically has only a very indirect connection with the source code?

I see more clearly now why I have collected so little code in the past.

A successful collection of code must also define its own ecosystem. The behaviour of this ecosystem should be as easily understandable as possible, because in order to understand the source code living in the ecosystem we must also fully understand the ecosystem. Now, the implementation of the ecosystem must not be necessarily part of our collection of code, but can be just an ordinary development project. As the collection of code grows, bootstrapping effects will grow also, until most of the implementation of the ecosystem can be understood through the collection of code itself.

A very interesting ecosystem for collecting code is the interactive theorem proving system Isabelle/Isar/HOL. As an underlying programming language it utilizes higher-order logic. This makes it possible to collect purely functional code (in principle, it is also possible to collect non-functional code with Isabelle), and to document the code by proving theorems about it. Isabelle can also generate code and therefore support me in principle in my everyday programming tasks. But Isabelle’s primary purpose is proving theorems interactively, not collecting code. Therefore Isabelle is more an inspiration for a code collecting ecosystem than an actual one.

For the time being the phlegmatic programmer will craft his daily code as carefully as possible and collect it using git.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: