COBOL

Abstract: To many people, Dijkstra's letter to the Editor of Communications of the A CM, published in March 1968, marks the true beginning of structured programming. That it influenced the industry is clear, if for no other reason than for the articles it spawned, ranging from "IF-THEN-ELSE Considered Harmful," to "The Else Must Go, Too," to "Programming Considered Harmful." In form and content, Dijkstra's letter is similar to his 1965 paper, which appears first in this collection. Description of the inverse relationship between a programmer's ability and the density of goto statements in his program is repeated, as is the emphasis on the limited ability of the human brain. Much of the discussion is somewhat theoretical in nature, and the typical COBOL programmer will hunger for some coding examples so that he can see why goto statements make program logic harder to understand. Echoing his 1965 paper, the last few paragraphs underscore once again why the subject of structured programming stayed out of the mainstream of the data processing industry for so long. As Dijkstra points out, goto statements were a subject of discussion among academicians as far back as 1959. But even today, people whom Dijkstra acknowledges --- names like Wirth, Hoare, Strachey, and Landin --- are not well known to business-oriented or scientificoriented programmers, so it should be no surprise that their ideas have languished for so many years.

Abstract: A COBOL compiler design is presented which is compact enough to permit rapid, one-pass compilation of a large subset of COBOL on a moderately large computer Versions of the same compiler for smaller machines require only two working tapes plus a compiler tape The methods given are largely applicable to the construction of ALGOL compilers

Abstract: A serious drawback in the application of modern data processing systems is the cost and time consumed in programming these complexes. The user's problems and their solutions are described in a natural language such as English. To utilize the services of a data processor, it is necessary to convert this language description into machine language, to wit, program steps. Recently, attempts have arisen to bridge the gap between these two languages. The method has been to construct languages (called problem oriented languages, or POL) that are (i) rich enough to allow a description of a set of problems and their solutions; (ii) reasonably close to the user's ordinary language of description and solution; and (iii) formal enough to permit a mechanical translation into machine language. COBOL and ALGOL are two examples of POL. The purpose of this investigation is to gain some insight into the syntax of POL, in particular ALGOL [1]. Specifically, the method of defining constituent parts of ALGOL 60 is abstracted, this giving rise to a family of sets of strings; and mathematical facts about the resulting family deduced. Now an ALGoL-like definable language (we hesitate to use the inclusive term "POL") may be viewed either as one of these sets (the set of sentences) ; or else, as a finite collection of these sets, one of which is the set of sentences, and the remaining, the constituent parts of the language used to construct the sentences. This is in line with one current view of natural languages [4, 5, 6]. The defining scheme for ALOOL turns out to be equivalent to one of the several schemes described by Chomsky [6] in his attempt to analyze the syntax of natural languages. Of course, POL, as special kinds of languages, should fit into a general theory of language. However, it is reasonable to expect that POL, as artificial languages contrived so as to be capable of being mechanically translated into machine language, should have a syntax simpler than that of the natural languages. The technical results achieved in this paper are as follows. Two families of sets (of strings), the family of definable sets and the family of sequentially definable sets, are described. Definable sets are obtained from a system of simultaneous equations, all the equations being of a certain form. This system, essentially parallel in nature, is an abstraction of the ALGOL method of description. Definable sets turn out to be identical to the type 2 languages (with identity) introduced by Chomsky [6]. Sequentially definable sets are obtained from a system

Abstract: As is evident from some of the other material reprinted in this book, much of the early discussion about structured programming and the related techniques was conducted by academic people and was published in scholarly journals, thus escaping the attention of the average software professional. In the rare instances in which structured programming was brought to the attention of the realworld programmer, the subject usually was greeted with loud hoots: "Bah! Humbug! What do those academic types know about real programming? By God, they should have to write a payroll system under a tight deadline with XYZ's version of COBOL. Then they'd stop yapping!" It's precisely because of this traditionally academic association that Terry Baker's article in the January 1972 IBM Systems Journal was so important. IBM's name, for the first time, was associated with top-down design, structured programming, and the related disciplines. Granted, IBM Systems Journal is not as widely read as Datamation or Computerworld, but it attracts more readers than the proceedings of the IFIP Conferences. The article served to call popular attention to the new techniques, and, as happened with virtual memory and several other technological developments, caused a substantial number of people in the field to believe that IBM invented structured programming! Who invented structured programming clearly is debatable, but IBM's role in popularizing it is indisputable. Many of Baker's topics deserve mention, either because of their initial impact, or because of their long-term implications. The first noteworthy concept is the major topic of the paper: the Chief Programmer Team. Baker's description of the team is a good one, and is illustrated with a real case study. The fact that the concept has been expanded and refined in later works, such as Fred Brooks's The Mythical Man-Month (Reading, Mass.: Addison-Wesley, 1975), should not detract from its worth. Nor should the realization, some seven years after the article's publication, that the Chief Programmer Team concept probably will never work in an ordinary EDP organization, for the following reasons: There are precious few chief programmers. Those that do exist are very expensive, and are not interested in working on small computers and mundane applications. In short, the Chief Programmer Team concept probably will work only in companies that are in the EDP business to make a profit. In most other companies, data processing is regarded as a necessary evil, and programmers (chief and indians alike) are tolerated with the greatest reluctance. Similarly, the concept of the program librarian, discussed at length by Baker, is less popular today than when it was first introduced. The concept of a program library is an important one, and its use has indeed been accepted, but the idea of hiring a human being to create, maintain, and control the library is becoming increasingly less popular. Most of the other structured concepts discussed by Baker still are used widely. Interestingly, Baker mentions top-down testing, but seems to attach relatively little importance to it, whereas I think it is one of the most important structured techniques. Baker also mentions structured programming, of course, and refers to Bom and Jacopini as the source of the idea; what's interesting is his emphasis on the formatting of structured code, and his effort to show how structured programming works with real languages such as PL/I and assembler. The other major significance of Baker's paper relates to the so-called New York Times project. For several years following publication of the paper, programmers quoted Baker's figures as proof that structured programming increases productivity by a factor of two or five, depending on your viewpoint. Statistics from a companion paper, "System Quality Through Structured Programming" [Paper 11], have been used by many EDP professionals to prove that structured programming leads to more reliable software. Indeed, the productivity and reliability figures of the New York Times project are impressive, but one has to wonder whether the Hawthorne Effect was a factor: Were the programmers more productive because they knew they were working on a special project? Or were they more productive simply because they were extraordinarily gifted programmers? Was the success of the New York Times project the result of the people or was it because of the particular organization of the people ? Questions like these still are being debated, and they will continue to be debated for several years to come. Significantly, Baker's paper first brought the questions to everyone's attention.