Third installment in this series, here is Part III of my essay Creationist programming vs Evolutionary programming. Previous installments: Part I (Creationist programming, The Devil), Part II (Intelligent Design, Polytheism).
Unintelligent Design
Intelligent Design was once a great progress in how to approach software creation, but sooner or later, you must realize that it doesn't describe reality accurately. The design of most software is just really bad; the issue isn't that errors creep in that corrupt a perfect understanding, it is that the understanding was far from perfect to begin with. We must recognize that all too often, the programmer God is just plain stupid. And so, the next stepping stone on the way to better programming paradigms is: Unintelligent design.
God may have an intent, but he's a blind idiot who doesn't know
exactly what it is he wants or how to achieve it.
He not only makes gross mistakes,
he writes plainly erroneous code that can't possibly work.
Tools to help him design programs will thus include
helpful messages from his compilers
for error diagnostic and recovery:
their role isn't to tell an intelligent programmer
the devil crept in while you weren't looking,
just have a look, you can obviously see him and chase him
,
it is to tell the unintelligent programmer
what you did was stupid, here is the explanation why
,
for it would be hard for his limited intellect to figure it out all by himself.
Syntax checking, type checking and various kinds of advanced semantic checking
are invented to catch the more or less obvious errors
and converge more quickly towards what the programmer would mean
if only he were capable of forming coherent intent.
Interactive help, manuals and hints constantly remind the programmer God
of the things about which he should know better.
Integrated development environments help God play with the code
and get faster answers as to whether or not his ideas make sense.
All the software interfaces are made idiot-proof
by making languages more abstract and completing them with ample
compile-time and run-time checking.
Tools do most of the work and clever interfaces try to present things
so that complexity is managed away for the stupid user,
and all decisions may be done based on a shallow limited view of the world,
the only kind that fits the programmer God's tiny brain.
There is no shortage of imaginable tools and prosthetic devices
to help the programmer God cope with his mental disabilities;
and these tools are themselves limited
mainly by the inability of their own godly program designers.
When a devil adds machine malfunction to operator dysfunction, testing becomes something to take seriously and systematically. When multiple gods are involved, the many resulting processes running at the same time must be protected from each other; the many parts of the software are tested separately, and contracts for what happens at their interface are attemptedly defined and enforced. Because the programmer gods cannot be trusted to remember all the issues with the software, some software must be used to systematically track those bugs and issues. When some of the programming gods are malicious, you're glad they are idiots, too, and you bury them under the weight and complexity of security features that will catch each of the more obvious malicious types of behaviour.
Lamarckism
Whether software is designed by intelligent or stupid gods, or something else altogether, we importantly may understand that software changes to adapt to new circumstances, and focus on the nature of this change. That's Software Lamarckism.
Filesystems may remember many versions of the files they hold, each with a different version number. Software releases are numbered too. Because many gods may be working at a time, a piece of software may exist along many different development branches. To understand the differences introduced, whether they were intelligent, stupid or malicious and what to do of them, tools computing differences between files are created. To merge the intelligent changes and the fixes to the stupid and malicious ones along the many different branches, tools are created to apply computed differences to branched files. Revision control and change management is born, and continuous backup remembers all previous versions of tracked files.
Lamarckism is not a complete theory of why and how change happens, but it introduces a useful focus on change. It is thus the starting point for more elaborate theories that will explain the development of software in the terms of this incremental process of change.
TO BE CONTINUED...