Historical Perspective

    The purpose of this post is to provide a synopsis of the evolution of program aspects as they relate to maintainable programs.  This is also intended as a prelude for how design object oriented programs for maintainability.

    As always the information here is based on my own experience.

    In the beginning programs were written in machine code or assembly code. This type of code is characterized by:
1. minimal separation of code and data.
2. any data or code element is accessible from anywhere in the code.
It worked well for small applications but as the code grew in size and complexity it required a lot of skill and discipline to create anything close to maintainable code.

    By the time I learned programming, FORTRAN and COBOL were widely used. Both of these are high level languages. Both of them had subroutines which organized code such that access to code inside them was not possible.  Both had data structures which when combined with, subroutines provided limited data access.  The main significant effect was to allow a separation between application data and control data (loop indexes and variables used to control logic flow).

    COBOL introduced the concept of records. This provided a way to organize dissimilar data primitives in a single data structure. To me this is significant because it led to what was a major mile stone of maintainable software.  Most often these records were stored in files and these files were used by different programs this created a huge amount of maintenance work. The solution to this problem was the concept of a data base. A block of data was added to the front of the normal record data which mapped record field names to offsets in the record. Basically this provided a symbolic name for fields in a record.

    After these simple beginnings, the number and nature of programming languages expanded rapidly.  Some of the most successful of these language types are: Function, Rule and Object based.
These and many others were created to meat specific needs and are often problem domain specific.
All of them are useful but when taken to the extreme or misapplied can result in code which is at best difficult if not impossible to maintain.

    Function based languages (such as LISP) became popular at least in academic circles. The main characteristic of such languages is that all code is represented as functions. In a pure functional world this means that a functions contain no state information which in turn means that when called with the same arguments the same result is returned. When studying such code it is easy to predict what the code will do. However, because of how logic control must be represented, in many cases it makes logic changes difficult to do correctly. The other situation it breaks down is when reading files because making repeated read calls will nearly always produce different results.

    Rule based languages (such as PROLOG) came into wide use in Artificial Intelligence applications. Programs written in these languages consist of a set of 'rules' of the very general form
"if <condition> then <action>" . In most cases the if and then are only implied. Probably the most widely used applications of this type are "make scripts".  The order in which the <actions> are executed in is depends on the initial data supplied and the results/side effects of preceding actions.
Applications involving few (perhaps less than 30) rules are very easy to maintain. As the number of rules increases, the more difficult it becomes to predict what the exact effect of a given change will be.

    Object based languages (such as JAVA) are currently popular. In all cases, the main objective is to encapsulate code and data structures. Some of then separate code and data, others make no such distinction. An other main characteristic of these languages is the that objects either can or must be created at run time.  Both of these characteristics can be a great help in creating maintainable software. Like all programming ideas/paradigms I have worked with or read about, can when taken too far can result in programs which are very difficult to maintain.