The Programmer and N.E.C.R.O.

A computer programmer noticed that he was not able to type very much in a single day.  But he mused that if there were a large number of software bots working on his code, then they might be able to proceed via totally blind trial and error.  So he decided to try an experiment.

In the initial version of his experiment, he established the following process.

1. The software was reproduced by an imperfect method of replication, such that it was possible for random copying errors to sometimes occur.  This was used to create new generations of the software with variations.

2. The new instances of the software were subjected to a rigorous test suite to determine which copies of the software performed the best.  The worst performers were weeded out, and the process was repeated by replicating the best performers.

The initial results were dismal.  The programmer noticed that changes to a working module tended to quickly impair function, since the software lost the existing function long before it gained any new function.  So, the programmer added another aspect to his system — duplication.

3. Rather than have the code’s only copy of a function be jeopardized by the random changes, he made copies of the content from functional modules and added these duplicated copies to other parts of the code.  In order to not immediately impair function due to the inserted new code, the programmer decided to try placing the duplicates within comments in the software.  (Perhaps later, the transformed duplicates with changes might be applied to serve new purposes.)

Since the software was not depending on the duplicates for its current functioning, this made the duplicates completely free to mutate due to the random copying errors without causing the program to fail the selection process.  Changes to the duplicated code could not harm the functionality of the software and thereby cause that version to be eliminated.  Thus, in this revised approach with duplicates, the mutations to the duplicated code were neutral with regard to the selection process.

The programmer dubbed this version of his system N.E.C.R.O. (Neutral Errors in Copying, Randomly Occurring).  He realized that even with these changes, his system would not yet fulfill his hopes.  Nevertheless, he looked upon it as another step of exploration.  In that respect it was worthwhile and more revealing than he had anticipated, leading the programmer to several observations as he reflected on the nature of its behavior.

Under these conditions of freedom to change without being selected out for loss or impairment of current function, what should we expect to happen to the duplicated code sequences over time and over many generations of copying?

And why?

[p.s. Sincere thanks to real computer programmer OMagain for providing the original seed of the idea for this tale, which serves as a context for the questions about Neutral Errors in Copying, Randomly Occurring.]