In 1974, my manager asked me to evaluate the new, highly touted discipline called "structured programming."

I was skeptical. At that time, I was programming in COBOL. In those days, COBOL was somewhat deficient in the amount of control structures provided. I had not yet read Bohm and Jacopini so I had no idea that the control structures of COBOL were more than adequate for the task. I suggested that I wait to perform a structured programming experiment until a new project came along.

In July, I was assigned a new project. The Chief of Naval Operations (CNO) Budget Office was in need of a text editor that could edit the descriptive portions of records in an indexed sequential file. The program would be developed and executed on a Unisys 1106 main frame computer. Unfortunately, the Budget Office also knew about the University of Maryland Text Editor (med) which, for all intents and purposes, replaced the Unisys provided editor (ed). The Budget Office wanted the interface to be "just like med" a seemingly impossible job for the short project time (three months). Fortunately, I found that med contained an API that would allow me to use the editor against extracted textual fields of the indexed sequential file¹.

So it began. For this project I could not use a GOTO statement, a standard tool of the COBOL programmer of those days. I struggled with the problem. It wasn't that the solution was difficult; the solution was difficult without using GOTOs. Finally, in September, I finished. When queried by my manager, I told him that the programming effort took longer than it would have had I not used the structured programming paradigm. We agreed that, even though some rather impressive academians had suggested that structured programming was the way to go, we would shelve further use of the method. I placed the code listing in one of the drawers of my desk and returned to programming in my normal unstructured way.

Then, in December, I received a call from the CNO production office. It appeared that a program that I had written had blown up. The production office provided the symptoms and the name of the program. I looked in my drawer and found the flawed program. When I opened the listing, I realized that this was the program that I had struggled with. As I reviewed the code, in light of the comments provided by the production office, the bug just seemed to jump from the page. It was such a simple error. But had I written the code in my normal manner, I would never have found the problem so quickly. After about fifteen minutes, during which I recoded, recompiled, and rebuilt the software, I called the production office and advised them that the software was ready for reinstallation. Neither they nor I could believe how quickly the bug was found and fixed.

Since that December day in 1974, I haven't used a GOTO statement in my work (excluding assembler, of course).

¹ Some interesting points about med. The editor was completely written in assembly language. I never found a bug (the author, Kern Sibbald, told me that after a few years of 15,000 students pounding on it, all of the bugs had been found).

The API performed a truly interesting procedure to allow editing a file when invoked through the API. The invoking program first placed the text to be edited into a temporary file. Then the med API was invoked, passing the name of the temporary file. Upon invocation, med copied the invoking program's data bank contents into the diagnostic file. Then it copied the med executable into the program's old data bank and jumped to the med entry point. med now replaced the instruction bank of the invoking program with the text to be edited from the temporary file. From this point on, med acted upon the user's commands. When the user ended the editor session, med followed the steps in reverse. I think it's amazing what brilliant programmers like Kern can produce.