Second installment in this series, here is Part II of my essay Creationist programming vs Evolutionary programming. Previous installment: Part I (Creationist programming, The Devil).
Even with the Devil variant, the pure Creationist approach to programming soon proves insufficient to explain how Software comes into existence, and why programming is such a difficult activity. As projects grow bigger, it becomes obvious that a whole software system cannot be completed in one go. The sheer volume of it makes it impractical. But it is possible to create the software in many steps, starting from foundations and building layers upon layers, bootstrapping complex structures from simpler ones, shaping tools and tool-making infrastructures, replacing parts with better ones as the need and opportunity arises, building scaffolding that may get destroyed later possibly leaving fossils along the way, all according to a carefully designed master plan. This programming paradigm has a name: Intelligent Design.
Intelligent Design is a most common paradigm amongst software professionals and amateurs, whether in the industry or in academia, if only because it flatters them. Programmers realize that software problems are big, complex beasts, but have faith in their godly brainiac powers to tame those beasts through the reasonable, intelligent, systematic endeavour of well-trained specialists creating well-designed programs.
Within this paradigm are created and elaborated such tools and concepts as assemblers, formula translators, source code, operating systems, compilers, compiler-compilers, compilation management utilities, etc. Top down design, flow charts, modelling tools, hierarchically layered systems, the waterfall design process, and all kind of neat engineering practices follow from this paradigm.
Now of course, this paradigm has a devil variant: Intelligent Design with a Devil. Based on this enhanced paradigm, according tools are engineered into existence to counter the devil's work: editors to modify programs and remove bugs (based e.g. on line numbers), loggers, tracers and single-steppers to help locate bugs. Some small amount of reviewing and testing is added to the design process.
Another useful mixin for software engineering paradigms is the polytheism mixin. According to this partial theory, there isn't one God, with one Master Intent and consequent actions, but a lot of gods, each with his own intent and actions. It may be that many programmers are each a god partaking in some part of designing the Software; it may be that some God takes multiple roles to address the multi-faceted endeavour of Software design; it may be that God's intent changes with time, that God is moody and has tantrums.
God's ways are impenetrable, but enhanced theories of what God is lead to the design of new tools. To address the multiple programming gods, files are invented; as gods get organized in hierarchies, so are files organized in directories. Machines are time-shared, operating systems grow to manage multiple users, and eventually multiple users at the same time, each running multiple processes. Communication protocols are developed to exchange data between machines. Source code comments and formal documentation serve to convey intent and content between programming gods.
The devil mixin can also be combined with the polytheism mixin. The devil may have multiple aspects that each have to be addressed separately. The apparent or actual polytheism could be explained as a one God's multiple personality disorder, and the devil as a symptom of His schizophrenia. The devil may be a God himself -- a malicious programmer. Any of these explanations for errors in God's Design can lead to new techniques to address the identified sources of error. User accounts are protected by passwords; files and other resources have usage restrictions, and will be backed up; redundancy checks are added to communication; errata complete documentation, and pages are intentionally left blank to prepare for them.
TO BE CONTINUED...