Return to Jim Pottmyer's home page | Jim's other writings
1979 August 10
Dr. Selden L. Stewart
Technology Building, A-267
National Bureau of Standards
Washington, DC 20234
Dear Dr. Stewart:
In our discussions August 9, we touched briefly on the future of COBOL. In the press of having to talk about many things in a limited time, I don't think that we achieved closure on this topic. Here are a few of my thoughts to amplify upon what I said:
I doubt that COBOL will be seriously considered as a language in which to implement operating systems, communications processors, very widely used utilities, and similar software. Probably 90 per cent of the code written (at the source level) for such systems could easily be done in COBOL today. Most of the code is devoted to rather mundane moving and reformatting of data, table searches, etc. COBOL does not, however, interface easily with other languages needed to do the last 10 per cent. Until parameter passing, file I/O, and message handling interfaces are standardized, there is a strong argument for keeping things simple by having a single implementation language.
Whether COBOL could be enhanced to be a single system implementation language is then the question. Four factors inhibit the use of COBOL for the last 10 per cent of code written as system programs. These are:
In conclusion, I think that problems with privileged state execution,
asynchronous processing, and I/O primitives can probably be solved acceptably
(even if not easily) if someone wants to make the effort to push for solutions
in the CODASYL COBOL Committee. The question of privileged state execution
might not require committee work. Instead, what we need is a pioneer to
"go out on a limb" in defining a system programming subset and
who is willing to foot the bill for a new code generator for an existing
compiler.
To solve the efficiency problem, though, would depend upon some restructuring of the industry. I don't think that there is any technical problem in developing compilers with object code efficient enough for any system program. The problem is an economic one. Until there are incentives to develop compilers which produce very efficient object code, any pioneering effort in using COBOL for system programming would result in a "curiosity." We could demonstrate the feasibility of producing efficient code; but the idea would not take root.
One of the strengths of COBOL is that its specifications are written in disciplined natural language. However, as the language has grown, it has become more and more difficult to introduce desirable new features because of the danger of introducing unintended side effects in changing a specification. Over the next ten years, I hope that the techniques of specification are examined and improved. When writing proposals to change COBOL, most time should be spent making decisions and answering questions. Presently, most of the time is devoted to figuring out how to write down the new specifications. I would not want to abandon disciplined natural language as the specification technique. I would like to see the specifications modularized to minimize side effects.
The many disparate ways of testing for and reacting to status conditions in COBOL are an impediment to learning and using the language. Over the next five years, I hope that a consistent way can be devised for exception handling. An unresolved question is whether exception conditions defected in an operating system (say, by a data base control system or a message control system) should be reported with tile same status codes in all standard languages. I suspect the COBOL community would be willing to say yes. But, I suspect that FOPTRAN programmers would rather live with a much smaller set of, say, data base exception status codes. In COBOL, it will Probably be necessary to "grandfather" some of the old ways of handling exception conditions.
In the data base manipulation facilities of COBOL, I would expect to see advances made along the following lines:
To facilitate testing, it is desirable to be able to trap the execution of a program and to be able to display data and status values. The present inclusion of a lot of debugging facilities in the COBOL language does not answer this need well. (I personally oppose taking these out until I'm sure that there will be something better in their place.) The best way to go is to have the COBOL compiler generate, on demand, an output of a "program schema." This program schema would associate addresses in the generated object program with user-names of programs, procedures, and data items written at the source level. The program schema and the object program would be inputs to some sort of utility program (batch or interactive) used for debugging or testing.
Left-brain-dominant persons (analytically and verbally oriented) probably find COBOL's procedural orientation comfortable. Right-brain-dominant persons (synthetically and heuristically oriented) would probably like better the style of state definition. Since left-brain types tend to do good committee work, the state-definition style of programming has received short shrift in COBOL. Report writer is the only facility with a strong flavor of state definition. In spite of the argument that COBOL is already "too big,' I would favor some small-scale attempts to add static programming facilities. These would admittedly be redundant with procedural capabilities. (Hopefully, a person who didn't like them would not even have to learn how to use them.) In the end, it may prove impossible to wean away the right-brain people from whatever language (APL?) towards which they feel affection.
One of the great strengths of COBOL is that, contrary to popular opinion, it is not verbose. The things which must be done often can be coded with great economy of effort. Very orthogonal languages either 1) demand that a lot of procedural code be written to accomplish what a single COBOL statement will do or 2) encourage the development of an author-unique Humpty Dumpty dialect through language extension features. I favor adding new features which can be demonstrated to achieve economy of effort. The difficulty, though, is demonstrating new features. As more capabilities appear in COBOL itself, the demand for macro preprocessors oriented to COBOL is likely to decrease. Any new ease-of-use feature must overcome considerable opposition from the quarter which asserts that COBOL is "too big."
When language features have not survived the test of time, they should be removed if the COBOL specifications can be significantly simplified or if compilers can be built much cheaper without them. COBOL is so widely used that, no matter what feature is proposed for removal, someone is sure to scream loudly about any deletion of capability. It is very difficult to justify removing anything from the language without hard evidence on what the impacts really will be. The CODASYL COBOL Committee has recently approved proposals to remove the CORRESPONDING option and to remove abbreviated combined relation conditions. I suspect that the former deletion is justifiable. Compiler implementation would be a lot simpler without the CORRESPONDING option; and very few programs are likely to be impacted. My intuition about abbreviated combined relation conditions is that they are used very widely. I doubt that paying a few dollars less for a compiler would make many users want to undergo the trauma of converting most of their programs. But, the decibel level of complaint is likely to be comparable for these two deletions. I would very much like for a large data base of COBOL source programs to exist somewhere so that statistics on actual use of language features could be obtained. In the absence of good statistics on use, I think that it will be difficult to remove unused features. Unless unused features are pruned from the language, there is little room left to add in desirable new features.
The major product of a compiler for most of its executions is the source program listing. The object code from most compiler executions is thrown away without ever being used. The source program listing from almost every execution is used. With an emphasis on fast compilation for passing benchmarks, the quality of diagnostics and cross-references in listings is uniformly sorry. (Since the answer to a capacity constraint is to buy more hardware, there isn't much reason for an implementor who is a hardware vendor to improve listing products to halve the number of compilations and reduce resource utilization.) There is much room for improvement of diagnostic messages and cross-reference information. I don't foresee much interest in developing standards in this area. Probably the best avenue to improvement is to encourage buyers to give great weight to the quality of listing products in competitive acquisitions. Some "guidelines" on evaluating COBOL compilers would be helpful.
An idea which has been kicking around a long time is to add a function capability to COBOL. Doing anything with this is inhibited by specification side effects. A proposal to add functions must necessarily be very long to clean up these side effects. Very long proposals move very slowly even with somebody to push them. Right now, nobody seems to be pushing for functions on the CODASYL COBOL Committee. If anyone feels strongly enough to put in a lot of individual effort in proposal rewriting, there could be intrinsic functions in COBOL within a couple of years (in time to make the 1986[?] standard). User-defined functions would have to face arguments against Humpty Dumpty languages. I think, however, that once intrinsic functions are disposed of, it would be possible to add in user-defined functions.
There is a very definite problem with the number of reserved words in COBOL. Over the next five years, a solution must be devised. I would suggest that there be a limit of about 350 reserved words -- and we are already over that. If function references are handled in a way I proposed before Defense Communications Agency resigned from the CODASYL COBOL Committee, functions could provide lots of new capabilities without adding to reserved words. There is a lot of sentiment for avoiding growth in the reserved word list of COBOL. I hope that some consistent rules evolve over the next three or four years for techniques to grow the language without adding reserved words. We should then figure out how to prune out some of the reserved words already there (with appropriate "grandfathering" over one standard's cycle).
Programmers simply never get around to writing all of the procedural code which ought to be written to check data items for valid values. Some facility is needed for specifying in the Data Division what the allowable values are for a data item. Some sort of automatic checking should then be invoked during the execution of certain statements. I don't think that this concept would meet much opposition. We're just waiting for the right proposal.
COBOL seems to be thriving. The CODASYL COBOL Committee and ANSI X3J4 both seem to be working. There are obvious problems that implementors have more to spend defending their interests than users can afford to defend theirs. A large class of users exists in the banking industry. Yet no bank is quite a big enough user to undertake committee membership. My observation is that. about five person-years per year must go into a committee's work in order for the synergistic effects to dominate over the diseconomies of committee operation. This should probably be divided about half and half between meetings and individual efforts. Both the COBOL Committee and X3J4 are probably benefiting from Over twice this minimum threshold of effort. I think the result is better than could be obtained by individual effort. I wouldn't recommend tampering too much with something which works.
(Even where insufficient effort is available to a committee to be productive in arriving at creative solutions, there still may be justification for having a committee. A committee can be used to legitimize the results of individual efforts, to distribute the blame in case of failure, &c.)
Looking ahead for the next ten years, some of the things which may impact COBOL are:
I didn't really intend for this letter to run on to this length. I got
somewhat carried away. The above comments set out fairly completely my
opinions on the future of COBOL.
Sincerely yours,
James J. Pottmyer