This is a computer-based concept that explains how various functions programmed into computers are combined, and recombined, to achieve new capabilities. The idea of combining functions on a computer is pretty old and very well established. Programmers have not only been strongly encouraged to recombine functions from the beginning of commercial programming, but a mark of success of a programmer is how well his or her work has created for re-use and how often re-use has paid off. By way of preface, this explanation starts with the most elemental functionality that programmers themselves use regularly in their work as creators of low-level software and extends to notions of recombinant systems. To understand recombination, it is also necessary to understand the notion of a protocol as it applies to a computers.

The following primitive example of a re-usable program is intended to help non-programmers understand a bit about how the idea of recombinant functionality is operationalized in programming environments at a low level. It's a bit more story and metaphor than actual history, but the concepts are way more important than historical accuracy.

Consider the idea of a function that gets the time from some kind of clock build into a computer system. Lots of computer programs need the current clock time for myriad reasons. Well, in the early days, this was not so trivial a matter as it has become today. Someone had to put a clock in a computer and then write some software to use it; that is, transfer some kind of representation of the current time to become data usable by a computer program. Of course, it would be silly in a business programming environment for every programmer to be required to invent this particular function considering how useful it would be for everyone, so computer programming shops would assign someone to write a program that provides the time or buy a computer along with the software that performs the function.

Now consider the problems that arise when this kind of reusability is undertaken. There is first of all the assumption that the one function that everyone uses provides the data from the clock in a form that is usable for all possible purposes. Then there is the program of arranging for everyone to obtain a copy of this software and then to figure out how to use it reliably. These may not sound like issues today when we're all so accustomed to sharing all kinds of data and capabilities over the internet without the slightest consideration of these matters, but what we take for granted today is the product of millions and millions of hours of problem solving among programmers and system architects to make such things easy to do.

Back to our problems. One way, in the old days, might have been for everyone to have a printed copy of the code that performs the function and each of them just types in a copy wherever it's needed. That would work fine, but what if someone finds a tricky little error in the code? A new version of the code would need to be issued to everyone and they would all have to go back to the programs they wrote and fix them.

Non-geeks, please hold your nose for a moment and try to play along. If you've never even seen or imagined a computer's commandline, please bear with me.

The commandline is what froze personal computer users in the old days. Instead of the marvelous graphical user interface (GUI), there was a blank screen with a blinking cursor, like a word processor, and it was up to you to know what to type. If you didn't know, there was apparently no way to find out, unlike the GUI that allows you to find out what is available because all the possibilities are displayed as desktop icons, or menu items, or something that you can discover by looking around. The problem was not that a commandline-based system was so difficult to use, but that learning to use it felt tangential to the real purpose of the computer, whereas simply clicking on an icon using a mouse was memorable. In truth, once mastered, command line systems are extremely efficient and offer combinatorial opportunities that GUIs classically lack - which is where this discussion is going.

The Unix commandline allows the adept user to combine the functions of programs together in ad hoc arrangements as the mood strikes when problem-solving. The method involves stringing commands together in a logical order, passing the output of one program into the input of another program. And, of course, the commands themselves can be pre-stored in a text file (called a script) that can serve as the source of commands instead of the user’s keyboard. If you consider that scripting is actually programming, then we’ve got computers controlled by programs as if a person was sitting at the keyboard typing astounding command sequences, all as an alternative to GUIs. And, finally, whereas those who are incapable of using a computer without a GUI generally regard commandline interfaces as limiting, the opposite is, in fact, true.

There’s an entertaining book about all this, In the Beginning … was the command line (Stephenson, 1999a).