PLEASE RETURN TO
CDR GRACE M. HOPPER USNR

to be presented by E. J. Albertson Methods Consultant, Methods Planning Division before The Computer Applications Symposium sponsored by Armour Research Foundation of Illinois Institute of Technology at Chicago, Illinois on October 28, 1959

Although the title of this presentation could be interpreted to mean a comprehensive review of all current developments in common language programming for business data systems, let me assure you that it is not.

First of all, I do not know all of the current developments; and if I did, I suspect that all I could do in the allotted time would be to name them.

There is, however, one current development that I would like to review for you and that is the work of the Committee on Data Systems Languages which was formed as a result of a conference of users and manufacturers which met at the Department of Defense in May of this year.

As a preface to this review, I would like to present a summary of common language programming requirements from the business user’s viewpoint. It seems that everyone except the user knows what the business user needs and wants. Users are accused of not knowing their requirements. I suspect that they know what they want, but are being told that they can’t have it.

I will not presume to speak for all business users, but rather for a segment that believes they know what they want and are prepared to assist in getting it. Of course, the term “user” is a broad classification and perhaps even worse, a generalization. For the purpose of my remarks, a user is the individual or function having the authority to decide on the use of a computer and responsibility for the results. The administration of this responsibility and authority is usually delegated to a level of staff and line management specializing in computers. It is in this area of delegation that an intimate knowledge of details and the pressure of consecutive emergencies develop the conviction that management cannot have what it wants.

Many reasons and excuses can be presented to support this conviction, but few solutions are offered. When a solution is offered, it is frequently criticized because it is far from perfect, or it shocks the sensibilities of the expert.

This situation is similar to the situation in sales organisations at the end of the seller’s market cycle a few years ago, when order takers were faced with the necessity of using persuasion to sell their products. Necessity was the stimulus necessary to change order takers into salesmen.

Data systems organisations are in a similar situation, where reasons and excuses are no longer salable, and an intimate knowledge of details and emergencies must be an incentive to solutions.

So far, I have said that management knows what it wants and I have inferred that it wants common language programming. What then is common language programming and why does management want it?

I believe that the second question should be answered first since the need usually precedes the desire. The need arises from the situation in which the user finds himself shortly after he becomes the proud possessor of a computer and fidgets uncomfortably as he waits for the scheduled benefits that his feasibility studies have shown he will receive. Expectancy degenerates into exasperation, and then into a desire for action.

An investigation of the situation shows that costs are accumulating rapidly and that the cutover of applications to the computer is falling far behind schedule. The reasons or excuses offered are that programming is taking longer than expected and that the computer is malfunctioning. Complaints to the manufacturer of the computer usually result in the correction of machine malfunction. But there seems to be no way to reduce the delay in programming except more programmers. This is done but the situation does not improve. Further investigation reveals that revisions to completed programs have become an important factor in the total programming work load. When the need of these revisions is questioned, it is learned that new or altered conditions in data processing have developed because of changes in the business requirements. New and better computers are now available and needed in order to meet the situations. Hence, programming must be revised. Furthermore, experience has opened the door to many new applications that had not been considered originally. In those instances where computers are being used in several geographical locations, it is discovered that the same or very similar applications are being programmed independently in each location.

An analysis of the total situation shows that a solution in the area of programming is needed. More programmers cannot solve the problem since there appears to be a limit to the number that can be used on each application. The solution appears to lie in more programming per programmer. It is discovered, however, that this cannot be done except by increasing the use of automatic programming. In looking for ways to increase the use of automatic programming, it is discovered that a whole new problem awaits solution.

This new problem has several facets. Automatic programming seems to be available in many forms. Each manufacturer offers automatic programming for his computer. Some offer automatic programming packages for each type of computer they manufacture and in a few instances, multiple choices for each computer. Considerable ingenuity is involved in the various methods and even greater creativity seems to have been used in designating the automatic programming methods with exotic and reassuring titles.

In general, the benefits of existing automatic programming methods have the following advantages:

  • Reduction of time required for original programming
  • Reduction of program testing time
  • Reduction of the time required to revise existing programming to changed information requirements.
  • Reduction in the time required to train programmers.
  • Increased use of personnel familiar with the information requirements of the business, but unfamiliar with computer programming technology.

There are, however, disadvantages in the use of existing automatic programming methods as follows:

  • Specialisation of purpose, that is, utility restricted to a small class of applications.
  • Limited ability in the sense that the method cannot program complex problems without reverting to programming in the intricate language of the machine.
  • Increased computer time for compiling the object or processing program.
  • Increased computer time for processing the data with the object or processing programs.
  • Resistance to the use of automatic programming methods by some experienced programmers.

There are, of course, other advantages and disadvantages but they are relatively less important. The total effect of the advantages and disadvantages mentioned is a major balance in favor of existing automatic programming. Users are generally aware of this and are taking advantage of these benefits.

But existing automatic programming does not meet the requirements of users, nor does it solve their problems except in a minor degree.

These requirements can be defined and met, and it is my purpose, as stated previously, to define the requirements in terms of what the user wants and why he wants them, and then relate this to the work of the Committee on Data Systems Languages.

What the user wants is a solution to the problem of excessive dollar and time costs of programming and to eliminate reprogramming costs. He wants this solution so that he can attain his objective which is to operate his business more efficiently.

The solution to this problem of excessive time and dollar costs for programming requires a common language for the writing of processing programs for electronic computers.

The requirements for this common language are that it be:

Independent - The language must be capable of expressing the processing procedure in terms of the problem, not in terms of the computer.

Simple - The language must be composed of simple English words and sentences.

Translatable - There must be an automatic (machine) method for translating the common language into the language of all present and future computers.

Efficient - The language must be efficient first in its use of human time and ability and secondarily in its use of machine time and ability.

Rewritable - Revisions to a program originally written in this common language must be made in the common language and not in the machine language.

Testable - There must be an automatic (machine) method for testing the logic and arithmetic of processing procedures written in this language.

One aspect of the development of a common business language is that it benefits all users and manufacturers.

The user will be able to set his applications on computers to suit as he chooses and at a cost in time and dollars that meets his requirements.

As a result, the volume of applications on computers is increased, and the manufacturers have a greatly enlarged market. Furthermore, both users and manufacturers can implement improved equipment as quickly as it is developed; and older equipment can be utilized by new users without concern over the time and dollar costs of updating equipment at a later date.

It has now been stated what the user wants (a common programming language), why he wants it (to make it possible for him to use computers to operate his business more efficiently), and the specifications or requirements of this common language.

There remains the problem of how to get this language. Attempts have been made in this direction but have met with failure, delay, or undesirable compromise.

There seem to be two general approaches available — first, legislation, which would take too long and be difficult of enactment; and second, voluntary agreement and use among users and manufacturers of electronic computers.

The latter seems more desirable and practicable. Efforts are being made along these lines, and I would like to review at this time a major effort in this area and one in which I believe success is possible and imminent, that is, the work of the Committee on Data Systems Languages.

The Committee on Data Systems Languages was formed as a result of a suggestion that the Department of Defense bring together users and manufacturers to consider the development of specifications for a common business language for automatic programming of data processing systems. The suggestion was made by a group representing users, manufacturers and universities, which had met at the University of Pennsylvania Computing Center on April 8, 1959, to discuss the problem of developing a common business language.

In response to this suggestion, the Data Systems Research Staff, Office Assistant Secretary of Defense, invited a group of user and manufacturer representatives to a meeting in the Pentagon on May 28 and 29, 1959, to consider the development of specifications for a common business language for automatic digital computers.

It was impossible to call together at the May 28–29 meeting a voluntary group of all persons and organizations having direct interest or competence in the problem. However, participation and assistance in this project is welcomed from all such persons and organizations, and it is planned to make the accomplishments of the Committee available to all.

It has been agreed that a common business language is needed and that it is possible and practicable to obtain it. Recognition has been given to the problem involved in designing such a language and to gaining universal acceptance. There is also a conviction that the language should be inherently simple in structure and precise in its communication between men and machines.

It has been decided that these requirements can be met by developing the language in three separate phases. Each phase is to proceed independently and concurrently with the other phases. Each phase has been assigned to three separate working groups reporting to an executive committee for direction and coordination.

The first phase of development is to design a common business language which is problem oriented and machine independent. Specifically, this means that the language can be used to state data processing procedures for problems that is to be processed on a computer but in a language that is common to all computers. The language, however, will be oriented to computer programmers.

The second phase of development is to develop this common business language to the point that it is systems oriented and computer independent. Specifically, this means that the language can be used to define data processing procedures independently of computer operational characteristics and be oriented to the conventional writing of business procedures.

The third phase is the investigation of the fundamentals and philosophies of data systems language towards a long-range goal that would combine the requirements of business language with those of a scientific language.

Perhaps a few words regarding the composition of the Committee on Data Systems Language would be appropriate at this point. Represented on the Committee are 26 large users and 10 major manufacturers of general purpose computers. The representatives from these users and manufacturers are experienced in the use of computers and have agreed to develop and implement a common language for the programming of business data processing applications.

The short-range group is composed of representatives from three users and six manufacturers. Their task is to design the first phase of a common language for the programming of business on digital computers. This phase of the language has been designated as being “problem oriented and machine independent”. This means that the language can be used to state data processing procedures for a problem that is to be processed on a computer, but in a language that is common to all computers. This phase of language development differs from the succeeding phases in that it requires the user of the language to have an elementary knowledge of computer programming. Subsequent phases in the development of the language will remove this requirement without changing the language.

The scheduled target date for completion of the first phase is December, 1959. Target dates for the completion of the second and third stages are currently under consideration. It should be remembered, however, that only one language is being considered. The three groups are working on separate phases of the evolution of a single, common business language.

Progress in the first phase exceeds progress in the second and third phases for obvious reasons. Work on the first phase was started much earlier, and work on the succeeding phases had to wait for the establishment of fundamental principles in the first phase. I shall, therefore, emphasize accomplishments in the first phase because more has been accomplished.

Developments in the first phase are as follows. The usage of automatic programming was surveyed to determine the actual experience of several users. The results of this survey were helpful to the group as a guide in planning their activities. The users surveyed were from the fields of education, manufacturing, government, and insurance and covered the use of eight automatic programming languages.

Within this group, the percentage of all programs written in automatic programming languages ranged from ten to eighty-five per cent. Programs written in the automatic language accounted for thirty to one hundred per cent of all machine coding.

It was learned that non-EDP systems groups rarely participated in systems development and computer programming.

The average elapsed time between initial system definitions and the first computer run using language coding was between four to twelve weeks as contrasted to automatic programming languages which was generally in the range of two to three weeks.

It was the consensus of opinion that the time to train new programmers to be effective in the use of an automatic programming language was about two weeks as compared to about two months for machine language programming.

The benefits of automatic programming systems were stated as the reduction of time required for programming, testing, debugging, maintenance revisions, and programmer training.

The quality of the object or processing programs was estimated as being between eighty and ninety per cent as efficient as machine language programming.

Applications programmed with automatic programming systems included payroll, sales statistics, product costs, savings funds, pension plans, premium billing, inventory control, and production control.

From the results of the survey, it was concluded that automatic programming, although primitive in its present state of development, was preferable to machine language programming and that improved automatic programming using a common business language was needed and could be developed.

From this point, work proceeded toward a study of the existing automatic programming languages being used by the group surveyed.

It was obvious from the start that the techniques and methods varied widely and reflected the specialized requirements of the computer for which they were designed. Reconciliation of this difference was a matter of reconciling the difference between computers. This, of course, would have been a difficult if not impossible task. It was established, however, that the fundamental requirements of a common language existed and that the task was to design a language that incorporated the best features of the languages studied.

One of the areas that required considerable investigation was the matter of data description and file description. It was established that data to be processed fell into three categories: first, that which is contained in files and enters and leaves the internal memory of the computer from specified areas; two, constants which are used by the program and must be entered; and, three, data which are developed internally and placed into a specified intermediate working storage area. Tables may be considered as belonging to any of the three categories, depending on how the table is used. Most often, the length of the table is the determining factor.

Users of electronic data processing systems have recognized that one of their major sources of programming errors lies in the area of file input and output, especially where the output from one routine is the input to another routine. The problems which arise as the result of making a correction to the file are difficult and costly to handle. It is desirable to have a means of making the correction in one place and having it reflected, automatically, in every routine that is affected.

A further requirement of the user is that it be possible to place routines defined in terms of procedure statements, data statements, and environment on one file several different computer systems with little or no rewriting of these statements required of a human being. Another extension of this same concept is that the entire system must be open-ended, that is, we “free to grow and develop.

A still further requirement is that the data descriptions be understandable to the user. It is felt, however, that the data descriptions should be designed and described by a top-level programmer who knows the problem, the medium on which and by which the data is recorded externally, and the internal working of the computer systems on which the problem is to be placed.

The approach taken is to distinguish between the part of a file whose handling procedures are user oriented and the part of a file whose handling procedures can be defined across computing systems. These two parts are referred to as file descriptions and detailed data descriptions respectively. It is recognized that for a given detailed data description, no two compiler systems will necessarily handle the information in an identical manner, and it is probable that no two computing systems will require the same minimum amount of information. However, the detailed data description has been specified in such a manner that one enters that which is termed universally essential and, in addition, that information which is required by a particular system or systems for which the problem is intended.

The form in which the information is entered is essentially a free form with the order of the information of the greatest importance. It is to be noted that under these rules, a particular user or manufacturer is not required to use the free form as input, but it is required that a free form listing be an output from the compiling system to be used both as a common media between different computing systems and as one of the requirements of the users’ “complete system analysis report”. It should be emphasized that the free form permits flexibility in going from one computing system to another and also provides the required open-endedness.

It is intended that the file descriptions and the detailed data descriptions will be kept on a library tape and called for as needed, much as with a library of sub-routines. Provision is made, however, to introduce a file as part of the program, such as one defines the constants and additional working storage. Another matter requiring attention was the establishment of general principles of statement language, a list of verbs, and a format for the use of the verbs.

The general principles of statement language established precise rules for the set of characters to be used, word construction and usage, and the formation of statements.

A total of 23 verbs was established for the functions of arithmetic, input-output, test and control transfers, data movement, endings, and compiler directing verbs.

The format for the use of these verbs provided for the notation to be used for verb write-ups and definitions covering the function of each verb. Since it is not the purpose of my review to explain the operation of the common business language developed by this group, nor at this point to justify its use, I will not attempt to go into the details of its construction or application. Coverage of this aspect of development will be provided subsequent to the presentation of the finished write-up on the language which is expected next month.

The point I wish to make at this time is that a group composed of ten major manufacturers of general purpose computers and 26 large users of general purpose computers have worked together toward a common and mutually beneficial objective and have agreed to work together toward the practical implementation of this objective.

I believe that emphasis should be placed on the fact that the language at this point is a common business language that is being developed by users and manufacturers and that it is usable at this point, although its full potential is yet to be developed through the remaining two phases.

Again, it is essential to remember that the remaining two phases are the further development of a single language, not the establishment of another language.

Perhaps this can be explained by touching briefly on the work that is to be done in the phases which are designed to make the language more useful, to orient it to systems, and to make it computer independent.

This effort requires that languages and their use in human communication be studied for the purpose of recognizing, discovering, or establishing the fundamental principles of human languages. Following this, a study of the principles of the languages used for communication between machines is required. At this point, it is believed that the principles of communication between humans and machines can be simplified so as to make it possible to write problems and their solutions in terms of conventional business procedure writing.

This is an over-simplified statement of the job to be done, but it is not intended as a generalization. The work of the second phase is already in the preliminary stages.

The first step in this stage is to work toward producing a functional language for the expression of business problems in procedural form, and the second step is to deal with the problem of implementing this language for stored program computers.

Considerable progress has been made in surveying the areas requiring preliminary investigation. Specifically, two task groups are working separately on the fundamentals of language structure and business problems. The task group on language structure is charged with the responsibility of studying and developing a structure for the intermediate range language stage, specifying its syntax and finally filling out the language with words, phrases, sentences, paragraphs, etc.

It was agreed that in the initial stages of development, the specific problem of implementing the language for stored program computers would not be controlling, but rather the ability of the language to describe business systems. It was agreed that by describing business data systems it is meant, stating the procedures which constitute the system, that is, the statements of the required language will be procedural statements. It was further agreed that when the structure of the language is well defined, the problem of implementing the language for stored program computers will be examined, and necessary steps taken at that time to provide for implementation.

The task group on description of business problems was charged with the responsibility of reviewing descriptions of business systems and procedures, and determining the requirements which the proposed language would have to satisfy. It is hoped among other things that this task group may be able to uncover some typical procedures which might be capable of generalization. In any event, it is expected that they will review as many descriptions of business problems as they can, and will extract information which may be of value in the development of the language, as well as proposals to be used for testing the language as it develops.

This concludes the review of the work of the Committee on Data Systems Languages and the summary of the user’s viewpoint regarding common language programming requirements.

Although I believe that the work of the Committee on Data Systems Languages is directed toward a satisfactory solution of the programming problem and that it will be successful in reaching this objective, I feel that a solidification of opinion and interest in this subject is needed on a very broad base of users and manufacturers.

On the one hand, acceptance of the language developed by this Committee is voluntary on the part of users and manufacturers. On the other hand, there are many other ways this job could be done. These other ways would, perhaps, be more palatable to individual schools of thought regarding language techniques. Since there is no single ruling body on this subject (and I believe such a body to be difficult and undesirable to constitute at this time), these various alternatives of compromising on technique but not compromising on the fundamental principles of a desirable and attainable solution. The users and manufacturers participating in the work of the Committee on Data Systems Languages are now resolving minor conflicts of opinion in order to attain a satisfactory and practical solution, which will have mutual benefits that far exceed the minor adjustments of position that are being made.

The groups working on the solution are motivated by a mutual need and are contributing the time and talents of their companies and themselves to the solution. The results of their work will be available to all users and manufacturers, whether or not they have participated in this work. It is the intent of the groups to pursue their work to an early conclusion as possible. Further, it is not their intent to set themselves up as a permanent body.

It is their desire to solicit and use all of the active assistance of competence that is available and offered.

A few comments on this point may be in order at this time. It should be remembered that the groups working on this solution represent a large segment of users and manufacturers. Nevertheless, there are many other users and manufacturers who have interest and competence in computer programming. The interest of these other users and manufacturers is needed and solicited in order that these working groups can put more minds and hands directly to work on each phase.

Perhaps some may wish to participate actively in the work of these groups. Others may wish to express their interest and endorsement of the approach. Since all will have the opportunity to avail themselves of the results and benefits, it seems that all should think seriously on the subject of common language programming. There is a need for constructive assistance in this project by persons who are competent in the field of automatic programming and who, at the same time, are able to discover and implement ways to attain the objective. There are, undoubtedly, other ways to obtain the objective, but it is certain that there is no way at this time that would or could meet with the approval of all concerned.