• DOI:10.1145/135226.376106
• Corpus ID: 18845698

Technical correspondence

@inproceedings{Crawford1992TechnicalC,
  title={Technical correspondence},
  author={Diane Crawford},
  booktitle={CACM},
  year={1992}
}

• D. Crawford
• Published in CACM 1992
• Computer Science

I n 1968 Edsgar Dijkstra, prominent computer scientist from the Netherlands, published his comment in the Communications , "GO TO Statement Considered Harmful" (Mar. p. 147). The central assertion of his article fomented a revolution in the way people thought about programming. It also launched a kind of "inquisition," during which software grammarians sought to ex-purgate GO TO statements in much the same way well-meaning censors bowdlerize salacious literature. Cobol programmers were among those most immediately affected by the Dijkstra pronouncement. Many of these gentle people were wrongfully persecuted for use of the GO TO statement. Such persecution was particularly cruel since people who programmed only in Cobol were already unjustly regarded as the cretins of software by systems programmers and developers of scientific software applications. Once GO TO was relegated to the status of a software obscenity, steely-eyed programming managers who had not written a line of code in years began to dictate rules such as, "No GO TO statements are allowed in new program development ." Under the Cobol standards of 1968 and 1974, attempts to enforce the GO TO proscription resulted in some complex and myste-PERFORM CONSIDERED HARMFUL rious algorithmic gymnastics. The programming managers in most organizations quickly discovered that Cobol was not properly designed to accommodate the kind of procedural structures that could totally eliminate the GO TO imperative command. This discovery often occurred too late to prevent the creation of some exotic and unmaintainable Cobol code. The goals behind eliminating the GO TO were to enhance source code clarity, reduce maintenance costs, and improve algorithmic reliability. Unfortunately, prohibition of the go to diminished rather than improved the quality of much of the Cobol source code. Cobol, as originally designed, was not well-suited to "structured programming" because it lacked the more important language constructs required to properly support that style of programming. During the early period of "GO TO-less" programming, textbook publishers produced a plethora of Cobol pedagogy purporting to show the way to structured programming in Cobol. There were examples of programs, most of which were built around the following statements, using the PERFORM verb: PERFORM 001-Initialization. It was thought that using the PERFORM in this way would enable the program designer to create small modules that would be easier to understand and maintain. It was correctly observed that modularity would improve programs, and the PERFORM seemed to be the best available option. This was, …