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. One is that the author of this component, let's for argument sake imagine that we are using someones 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 there are errors however in the barchart version 1, we won't get those fixes if we copy the code. But if we link to barchart, and the author of barchart changes how you use the barchart module, then our code will break. So we are stuck between copying, creating duplication of immediately obsolete code, or we are at the mercy of breaking changes in the evolving component we reference.

The solution is that evolution of modules must proceed in a highly upward compatible way. To keep version 1 still working but allow new features, 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 version2 of the barchart plays music, you can send version 1 as an input 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 metatesizing cancer, move to a new location.