Simplification is easy

 Okay ready to write my program now...

Okay ready to write my program now...

Today we in the programming world are facing an explosion of code libraries. People are writing code all over the place, and to save duplication of effort, we are trying as a profession to share the previously done work. There are two problems that immediately crop up. Let's for argument sake imagine that we are using someone's bar chart making module, and that module was at version 1 when we used it. If we copy the bar chart code over, and incorporate it into our project as a copy, it will continue to work as it did. If we disconnect from the update stream, if there are errors in the barchart version 1, we won't get those fixes. If we link to the constantly evolving barchart code, and the author of barchart changes how you use the barchart module, then our code can, and likely will eventually break. So we are stuck between the choice of copying, creating duplication of immediately obsolete code, or being at the mercy of breaking changes in the evolving components we reference.

This in a nutshell is what is driving the explosion of slightly variated code bases, which today is exploding at a geometric rate. There are billions of lines of code written, yet every day it is ignored by many developers because who knows how good the code is, or what trajectory the code base is on.

The solution is that evolution of modules must proceed in a highly upward compatible way. To keep version 1 still working, but allow for new features to be added, one must change how a component is accessed. In modern languages, the only way to reference external code is to call a function with parameters. Once the parameters change in name, position, or quantity, most languages will break on that inevitable change. So the enemy of stability is function parameters, which have in most languages a rigid order. The other improvement one can make is to send a version number to all functions, telling the intention to use functionality as of version 1. Let's say that version 2 of the barchart plays music, you can send version 1 as an input parameter to the module, and then the designer can guarantee that version 1 behaves the same as before. 

How you communicate large and complex amounts of data to modules is the key weakness in modern languages. In Pascal, C, Fortran, COBOL, and other languages of the 60's and 70's you had records. Those were removed in Java, JavaScript, and many other languages of the 80's 90's and 2000's. If you don't have records, but amorphous objects, you then have a nightmare of missing information error states. So the tradeoff in module access is that either you force a rigid record structure, or the module code must increase in "toughness", the ability to not break if inputs are missing. 

In the old days, every function had an error return. This is now considered cumbersome, and in JavaScript for example one hardly ever sees error results being passed back or checked. This creates really flabby code, where errors propagate silently, and like a metastasizing cancer, move to a new location. It is gratifying to see error codes return in Go, however, that is not the best way to do error returns. Excel is the master at handling errors, and programming langauges would be well advised to study Excel more closely.