I'm writing an essay Creationist programming vs Evolutionary programming, based on a speech given at ENS in october 2005, and redacted, extended and polished under the purview of the loveliest of lovelies, my wonderful and everinsightful Lucía. In the hope of pushing myself to finish it, quick, I'll be publishing it in a series, of which this is the first installment.
I was once asked to summarize the main TUNES concept in a few words. My reply was that the central idea behind TUNES is the evolutionary paradigm for programming. What is this evolutionary paradigm? The opposite of the creationist paradigm. (Duh!) Now, what is...? Wait, let's examine paradigms for the appearance of software on earth: start from the initial naive paradigm of software creationism, and watch how it has evolved since.
Creationist programming
At first there was nothing; then, God zapped code into the computer, and Software came into existence.
The belief in this simple story is Software Creationism. The programmer is a God outside and above the machine; the program is his creation, implemented in the machine. The programmer God is perfect, and has a perfect program in mind; the actual program may not be perfect, but that's because it's a rendition of His platonic idea on an imperfect Machine. Though its form might be limited by the limits of the finite physical computer, the program is the expression of a perfect intent.
Software Creationism is not only the naive belief that non-programmers naturally form when confronted with the apparition of software, it is also the programming paradigm taught to students at most schools: in exercises and in tests students are expected to produce from scratch and on paper a perfect solution to a perfect specification; in assignments and projects, they otherwise have to write standalone pieces of code to be run and evaluated once by the teacher, software that should not rely on any code by anyone else or contribute to such, except through the documented interface provided by the system.
No programming tools are necessary in this paradigm; just a switchboard to insert the program into the machine. Who needs tools when you're a perfect god directly playing with memory at the binary level (or base ten, if that's your kind of machine). Programming the machine is best done in binary, directly from God to Machine, although it can be done in a whichever write-only language suits the expression of God's will.
The Devil
The story of software creation by a superior God is beautiful; however, anyone who has ever tried to program soon realizes that he can seldom get his programs to run perfectly at the first try, or even the second. Bad things happen: Bugs, typing mistakes, mismanipulations, cosmic rays, hardware malfunctions, errors in the program, etc. Happily, the simplest explanation suffices to account for it: The Devil.
There is a devil that modifies things in a way that counters God's intent. Whether this Devil is a personality defect within God, an opposing force outside God, or an artefact of the laws of Nature that God created is unclear and might really not matter. What is clear and matters is that the bad things that happen are the symptoms of the presence of dark forces of Evil. This Devil introduces imperfections in the way the machine works, and causes it to fail to perfectly receive the perfect message from the perfect God and thus to fail to embody His perfect platonic idea.
To keep this devil under control, appropriate tools pop into existence: punched cards or display consoles are used that can be read by the programmer God as well as written. Thus programs can be double checked, fixed, retried, stored, despite the attempts by the devil to make them fail. Programs must be read as well as written, decoded as well as coded, and thus come into existence all kinds of languages to express computation. Many software development practices are invented, to be followed religiously.
From a better (or less bad) paradigm for programming, we thus get better (or less bad) tools that allow us to improve software engineering and cope with the difficulties of the endeavour. This will continue to be true as we improve our software engineering paradigms.
Interestingly, anytime we find a new and hopefully better such paradigm,
we will always be able consider a variant of it
where some dark forces conspire to undo or corrupt
what the creative forces strive to achieve.
Thus, the idea of such opposing forces is a universal mixin
for software engineering paradigms, the devil mixin.
TO BE CONTINUED...