COBOL and Computer Science

Editor's Notes

• #2: Hi, my name is Andrew Turley, and today I want to talk to you about COBOL.
• #3: This talk is based on a paper called “The Relationship Between COBOL and Computer Science” by Ben Shneiderman. But it is also strongly influenced by Jean Sammet’s “The Early History of COBOL”.
• #4: Let’s get this out of the way: the relationship between COBOL and academia has been and still is … frosty.
• #5: Shneiderman’s paper presents three perspectives on why. Historical. Technical. And Social/Psychological. The purpose of this talk is to give you some background about COBOL so that you can understand what Sheiderman is talking about.
• #6: First, let’s talk about the early history of COBOL
• #7: April, 1959. At a meeting of “computer people” at the University of Pennsylvania Computer Center there was a discussion of the need for a machine independent common language.
• #8: May 1959. A followup meeting is held to further discuss the need for a common business language. Participants included government and industry employees and consultants. Academia was not well represented.
• #9: At the meeting it was decided that there should be three committees that would investigate the creation of a common business language. The committees drew members from these organizations. There were no traditional accademic institutions.
• #10: June through December 1959, the short-range committee explored language options to recommend a short-range composite approach that would guide the work of larger committee for the next year or two.
• #11: The short-range committee believed their work would be used by the intermediate-range committee, which would have time to develop a really good language.
• #12: Unfortunately, that never happened. The recommendations of the short-range committee pretty much turned into COBOL.
• #13: Sammet notes that had the short-range committee realized just how long it’s work would be used, they would have gone about their task quite differently.
• #14: December 1960. The same program runs on two different computers. COBOL is the this first real cross platform language.
• #15: August 1961. “COBOL: A Sample Problem” appears in the Communications of the ACM. It is 7 pages long, consisting of 2 and a half pages of flow charts, 3 pages of code, and no references to other work.
• #16: May, 1962. The Communications of the ACM puts out the COBOL issue. There are 13 articles about COBOL. Only 4 have references to other work.
• #17: Now let’s talk about COBOL as a technology
• #18: In order to understand COBOL, it helps to understand that goals that led to its creation
• #19: People wanted a language that could be used to solve business problems. In many cases, this meant reading records from files, combining information from those records, and writing new data out to new files.
• #20: People wanted a cross-platform language, so that the same code could run on many different computers. WRITE ONCE, RUN ANYWHERE!
• #21: There was a desire to have an English-like language, because it was thought that this would help broaden the group of people who could describe problems to computers. Here’s a PERFORM statement. Notice that you can almost read this as an imperative sentence.
• #22: The COBOL committee decided to create a verb-based language that had “few verbs with many options rather than a large number of verbs with a few options”. This meant that there were a smaller number of verbs to remember, but it also meant the syntax for using each verb was less uniform.
• #23: COBOL Programs are hierarchical. There are four required divisions. Divisions can have sections. Sections can have paragraphs. Paragraphs can have sentences and sentences are made up of statements.
• #24: Here are the parts of a COBOL program. As mentioned, there is an IDENTIFICATION DIVISION, an ENVIRONMENT DIVISION, a DATA DIVISION, and a PROCEDURE DIVISION.
• #25: The IDENTIFICATION DIVISION is where the programmer specifies the program name. It can also hold information about things like the programmer’s name and the date on which the program was created.
• #26: The ENVIRONMENT DIVISION contains environment-specific information for the program. The idea was that all of the things that were not portable between platforms could be isolated into this section.
• #27: The DATA DIVISION defines the structure of the input and output records in the FILE SECTION. Records are hierarchical, so SAMPLE-NAME can be used to refer to the part of the record that contains both the first and last name. The WORKING-STORAGE section defines variables and constants. All variables are global.
• #28: The PROCEDURE DIVISION contains the logic of the program. This particular program reads input records with names and birthdates, and prints out records of names and the generation that the person is from.
• #29: The program is broken up into two paragraphs, one called BEGIN and the other called REPORT-GENERATION. The sentences in a paragraph are indented.
• #30: The PERFORM verb is effectively a subroutine call. The UNTIL modifier means that it acts like a while statement, repeatedly transferring control to the REPORT-GENERATION paragraph until the sentinel value END-SAMPLE-DATA is set to TRUE.
• #31: Check out this nested if-else statement. One thing about early COBOL was that the period ended the entire sentence. In this case, if you left off the period then the next line, the one that begins with DISPLAY, would be part of the ELSE clause. It was easy to forget a period, and easy to miss it when reading code, so this kind of bug was common. Later version of COBOL added an END-IF.
• #32: There were some common technical complaints about the language. Early version of the language only had one string processing verb, INSPECT, which could only be used to count the number of occurrences of a substring, and do simple find and replace.
• #33: Every sentence could end with “AND GO TO”, which led to code that was hard to follow.
• #34: All variables were global. This made it important to coordinate work between programmers who were working on the same program. There were no parameterized procedure calls, only subroutine calls via PERFORM. Recursion was not supported. A mathematical notation of function calls was discussed early in the design of the language, but rejected as being too hard for non-mathematicians to understand.
• #35: Shneiderman proposes a number of what he calls social and psychological reasons for the rejection of cobol by the computer science community.
• #36: Data processing was not seen as an interesting problem. It was considered quite simple, compared to things like physical simulation and systems modeling.
• #37: Professors felt that teaching COBOL, a language widely used in industry, would reduce their universities to “trade schools” that simply prepared students for jobs.
• #38: COBOL’s english-like syntax seemed imprecise and unscientific.
• #39: In the end, what can we say?
• #40: COBOL was created with almost no input from academic computer science. In many ways, such as the decision to not include functions, it actively rejected an academic orientation.
• #41: COBOL was widely adopted and used. It was a good enough language, and it had the backing of some of the biggest and most powerful organizations in the country. In some ways, this popularity hurt COBOL in the eyes of academics.
• #42: COBOL was a flawed language. Jean Sammet and others involved in its development have spoken over the years about things that they might have done differently. However, it is important to remember that many of the decisions that were made seemed very reasonable at the time, and better alternatives were not discovered until later.
• #43: Thank you very much for being here. I’d like to thank the Papers We Love crew for inviting me here, and William Byrd for not running in horror when he heard i was speaking before him. If you’re interested in learning more about COBOL’s history, here are a few places you can start.