Editorial: Not So Much a Program, More a Way of Life

After many attempts at answering vital questions about programming, in lieu of writing an editorial, the time has finally come to get straight to the point. So with no further distractions or mucking around, let us once more focus and turn our attention to a vital question which requires an answer before we can even consider what to write about for an editorial: what do we mean by a program? ¹ I will attempt to avoid distractions, such as whether it should be spelled as ‘program’ or ‘programme’. The internet says ‘programme’ is the old way of spelling ‘program’ when it comes to computer programs, so let us take that as read. ²

Are programs dynamic?

Programs come in many guises. They can be dynamic, that is a script that is interpreted at run time. Alternatively, they can be static, that is requiring compilation. They can also be a half-way house, compiling to byte code, such as Java or C#. Please note, that static does not mean they never change. Has anyone written a program that never changed? ³ There is a slim chance a one line throwaway script might never change. I have heard rumours of such things, but never seen one. Whether a program is dynamic or static, if it has been in source control the log may indicate it is in truth always dynamic, or constantly changing. Code only tends to stagnate, or become truly static, when it’s dead. Perhaps code is like a shark. ‘I’m like a shark, I don’t swim backwards’ [ Google ], though perhaps many of us have done something along the lines of

  git reset --hard HEAD…

Forwards or backwards is still a change and therefore dynamic. More importantly, if the code itself is not in version control that is a potentially life threatening decision, if the person who failed to use version control is in striking distance. More positively, as Heraclitus [ Heraclitus ] said,

All entities move and nothing remains still.

sometimes taken as “You can’t stand in the same river twice.” Aside from Heisenbugs [ Heisenbugs ], wherein attempts to debug the code change how it behaves, a program tends to evolve and change over time, either meandering towards the requirements or trying to play catch-up with the requirements, or even trying to discover the real requirements. It could be argued that a program is its current code along with its history, including all the crime scenes to watch out for [ Tornhill13 ] and the bug tracker history and perhaps the documentation. Sometimes there is no documentation, or no version control. This leaves us with just the code as it is now. If the code is compiled, there is no guarantee this matches what’s in production. This is a frightening place to be. Sometimes, we have only the executable and no code. An environment including tests, useful documentation, version control and the code itself is a safer happier place to be. A program is much more than just something that can be run or executed.

Are programs executable?

Not all code is executable. Certainly some code will run on one machine and stubbornly refuse to even start on another machine, though some code is not designed to be run directly. Most of us will have used a variety of libraries, APIs, interface, protocols and similar at some point. Some of us may even have written libraries, hopefully managing the difficult task of making them easy to use correctly and hard to use incorrectly [97Things] .This sage advice tells us we are really writing code for fellow programmers, not the customer or the machines. The executable is for the outside world. The code itself is another matter.

Recently on accu general, a controversial quote from Bjarne Stroustrup [ Stroustrup ] caused a brief discussion:

I have yet to see a program that can be written better in C than in C++. I don’t believe such a program could exist.

By better, Bjarne explains he means ‘smaller, more efficient, or more maintainable’ and goes on to say:

Many then fall in love with their obscure and complex code, considering it a sign of expert knowledge. It is amazing what people can fail to learn when they are told that it is difficult and useless.

As stated at the outset, we might need a clear definition of program in order to evaluate this claim. One immediate response on the email discussion was “Program, sure. Library, not convinced.” ⁴ Is this difference significant? In terms of the wiring between a library and what uses the library, some may suggest that a C interface to a library is easier to work with from another language than a C++ interface, so a program and a library do differ. Nonetheless, on paper, if you’ll forgive the misnomer, both a program and a library are lines of code written in a specific language. At a high level, the main difference is simply that one can be run or executed while the other will be used by something that runs. Some sap ⁵ then side-lined the discussion, enquiring as to why such sporting terms as ‘run’ or violent terms such as ‘execute’ get used for programs. It seems the discussion has happened before, for example see the English StackExchange [ SE ]. It seems both words are rooted in the idea of carrying out instructions. The word ‘program(me)’ itself hails from Greek for a written public notice [ program ]. A variant of the meaning can be applied to people, wherein one is trained or perhaps brainwashed into behaving in a certain way. It is theoretically possible to train machines to solve some problems, though a long in depth discussion of genetic programming will have to wait for another day. The current ‘Testing Times’ series in our members’ magazine CVu has been skirting around the subject [ Polton ].

Are programs observable behaviour?

Having touched on Heisenbugs earlier, we realise that the same code doesn’t always do the same thing. Sometimes for apparently identical inputs we get non-deterministic outputs. This can be deliberate. For example, in order to approximate a difficult mathematical problem, a program may perform monte carlo simulation [ Monte Carlo ], producing various different values, driven by a mathematical model of the problem to be solved. The program itself will not be changed between runs, but a random number generator will provide different runs in order to cover the problem space and flush out an answer, by taking an average of the various outcomes. There are a variety of ways to make unchanged code behave in different ways. Many programs will use a configuration file which will point it at different data sources, or invoke different paths through the code allowing a user to flip switches or wave flags without the programmer having to change the code. Even without a configuration file, if a program relies on a data source which can change between runs, the observable behaviour will change even when the code does not. Furthermore, most people have war stories of misuse of a program, with users managing somehow to press an incredible sequence of buttons or provide other heretofore undreamed of inputs causing a spectacular crash. Even without malice or imagination, something very simple, such as attempting to run a program originally targeted at a 32-bit machine on a 64-bit machine can lead to surprises. A program therefore includes its code, its revision history, the bug history, any documentation, possible war stories from those who wrote it and the context in which it is run.

Given that the same code can do different things each time it is run, it is also possible to make different code behave in the same way. This might seem like a foolish waste of effort at first sight. Why would anyone rewrite a program in a different language in order to do the same thing? It’s not unheard of. Perhaps a team of programmers who were obsessed with C++ template meta-programming have just left (or been sacked) and those who remain only know python, so needs must. More positively, refactor – an often overlooked part of the test-driven development cycle – deliberately changes the code to make it easier to maintain, more beautiful, with less repetition, and so on while making sure the observable behaviour stays the same. Is the program the same program after the re-write?

Are programs a way of life?

No matter what language has been chosen, or which sets of libraries code uses, or how it has changed through time, it seems a program is more than the sum of its parts. The history of the requirement changes, code refactorings, bug reports, various tests, options in configuration, choice of compiler and dependencies all tell a story. The machines a program will work on, the coding style adopted, the language choices and idioms and manner in which it is released all form part of a program’s way of life. A program is far more than just the code you get from source control, assuming you are lucky enough to be in a place that uses source control. The context in which a program works, the manner in which it has been developed and the culture in which it was conceived all influence the code and in turn may influence those who work with the code. In a business, choices along the way were either knee-jerk reactions to crises or considered opinions to avoid crises. For your own personal project that may never leave the privacy of your own computer, there will still be a history and progression of changes and choices – which language, which compiler, is this a learning exercise or a Sudoku solver to stop those pesky kids troubling you? The only constant in a program, or indeed life, is change.

References

[97Things] Scott Meyers in ‘97 Things every programmer should know’ Kevlin Henney, O’Reilly, 2010 http://programmer.97things.oreilly.com/wiki/index.php/Make_Interfaces_Easy_to_Use_Correctly_and_Hard_to_Use_Incorrectly

[Google] Take your pick from googling “I’m like a shark I don’t swim backwards” it could be anyone – apparently sharks don’t die if they stop swimming.

[Heraclitus] http://en.wikipedia.org/wiki/Heraclitus#Panta_rhei.2C_.22everything_flows.22

[ Heisenbugs] http://en.wikipedia.org/wiki/Heisenbug

[Monte Carlo] http://mathworld.wolfram.com/MonteCarloMethod.html

[Polton] ‘Testing Times’, Richard Polton, CVu 25 v 4 and 5

[program] http://www.etymonline.com/index.php?term=program

[SE] http://english.stackexchange.com/questions/80974/where-does-the-phrase-run-code-or-run-software-come-from-why-run

[Stroustrup] http://electronicdesign.com/dev-tools/interview-bjarne-stroustrup-discusses-c

[Tornhill13] Adam Tornhill, ‘Code as a Crime Scene’ in Overload 117, October 2013

Footnotes

1. The title and strapline are from http://en.wikipedia.org/wiki/Not_So_Much_a_Programme,_More_a_Way_of_Life
2. US: program is the only spelling normally used. UK: programme is used in all cases except for computer code, in which case program is generally used. Older sources may use programme for computer code. http://en.wiktionary.org/wiki/program#Usage_notes
3. Recently seen on twitter: "never changed *since release* – several of the games I worked on, no patches, no sequels, code base thrown out, not repurposed." Thanks @codemonkey_uk
4. Tim Penhey
5. Yours truly