A Historical Perspective on COBOL (2020)

COBOL was my first professional programming language.

We wrote the code with a pencil, on coding sheets. The team leader checked it, and once it was deemed OK, we could type it in on a terminal.

It was a horrible language. The article speaks of code that "reads like a novel"; I swear I never read COBOL code that was easy to read. The problem was that COBOL doesn't lend itself to expressing structure. Combined with the fact that we were under commercial pressure to ship code, we shipped a lot of spaghetti code.

The idea that COBOL code is "easy to maintain" is nonsense. Any non-trivial COBOL program that is easy to read and maintain is going to be harder to write than an equivalent program in (say) Pascal, PL1 or ALGOL.

I worked for Burroughs; one of the super-powers of the Burroughs systems was hardware BCD arithmetic. It allowed a COBOL programmer to declare numeric variables with any specified number of decimal digits, and perform arithmetic on them with exact precision, easily. This is necessary when handling currencies, for example. Also, a hex dump of a BCD variable is precisely it's decimal value - BCD made it easy to debug.

It is said that COBOL is unsuited to systems programming. This is true; but it's not impossible. I was lucky enough to be sent on an "advanced COBOL course", in which I learned that the Burroughs COBOL compiler had seven passes; and that you could stop it during the later passes, and edit the intermediate code, before resuming the remaining passes. This meant that you could do things like access registers and IO ports. It blew my mind (but I never made use of those learnings!)

For many years, I denied that I had ever learned COBOL, for fear of being marked-down as an old fogey. Now I'm retired, I am an old fogey, and I don't give a tinker's cuss.

(I work in mainframes, but not directly COBOL.) COBOL could certainly be done better today, but its strength comes from the fact that it limits what programmers can do with it.

In the past, there was a divide between systems and application programmers. Roughly, the systems programmers took care about the details of the infrastructure and resource access, while the application programmers worried about the "business logic" of the applications.

After the microcomputer revolution, new languages emerged and this divide was lost. "Modern" languages such as C or Java do not make this distinction. Today, programmers are supposed to be interchangeable, and they are supposed to work equally well on system infrastructure and application logic. I suspect it's partly the pride, because infrastructure work is often seen as more attractive - all the distributed algorithms stuff, scaling, etc.

To me interesting question is, was this divide valuable and should we return to it? I think so. With the advent of functional programming, it is possible to understand applications a layers of translation between different languages (see https://degoes.net/articles/modern-fp-part-2), where the language of the business problem is at the top layer, and the language of the operating system is at the bottom layer. The (application) programmers, working on the upper layers, should specialize in the application domain, and the (system) programmers, working on the lower layers, should specialize in computer systems.

I remember growing up in the 80s and picking up disdain for COBOL because it was verbose. But then,

1. I recently found out that COBOL can calculate numerics to a degree of precision greater than most languages and libraries. It was a PITA to do monetary calculations right and it is built into the core of COBOL.

2. Reading the sample COBOL code, I realized though I can’t scan it fast, it is structured in a way that is not much different than reading or writing SQL.

3. Having written Ruby for 10 years, and spending a lot of time with DSLs and business domain languages, the aims of COBOL is really not that much different.

4. Having taken the long path through learning the design philosophy of Smalltalk, Christopher Alexander, sandstorm.io, Free Software, as well as my evolving thoughts on “regenerative technologies”, I am coming to the conclusion that it is important for end users to be able modify their computing environment for use in their local community. As such, COBOL may be a good case study for designing pattern languages.

>> A global pandemic in which more people than ever before are applying for unemployment is a situation that COBOL systems were never designed to handle, because a global catastrophe on this scale was never supposed to happen. And yet, even in the midst of this crisis, COBOL systems didn’t actually break down. Although New Jersey’s governor issued his desperate plea for COBOL programmers, later investigations revealed that it was the website through which people filed claims, written in the comparatively much newer programming language Java, that was responsible for the errors, breakdowns, and slowdowns. The backend system that processed those claims—the one written in COBOL—hadn’t been to blame at all.

One can bet good money on the expectation that the mainframes will be the last component of a system to crash and burn. Though to be fair that's not to do with COBOL, per se, it's just that mainframes are rock solid.

This article's opinion of COBOL is too positive, even if I agree that COBOL is sometimes treated too harsh.

The failings of COBOL are the failings of slow, bureaucratic entities. It works, but needs constant manual handholding to keep it on the rails. It assumes plenty of butts in seats with plenty of time. It assumes nobody complains if results are a week late and the first version is wrong. It assumes end users will threat it gently, do a lot of interpreting of codes themselves, and can be fired if they look behind the curtain.

These are not unavoidable technical blockers, but every programming language also carries a specific culture within it.

None of this should block unemployment payments, but all of this places COBOL firmly in the sixties to maybe eighties.

Article acts like having a 'richer' language approximating English makes it easier or more approachable, but whenever I've tried such languages I've found them harder. A programming language with simple and more orthogonal syntax like C is much easier to learn and reason about, than a language where you learn so many different verbs/constructs like COBOL or Ada.

And I think that -- depending on the problem -- you want a more succinct language to express the problem in. Maths is a good example: maths would be far harder if we described everything in plain English without ever resorting to symbolic maths. Formulaic maths allows us to focus more on the structure and meaning rather than the encoding.

I haven't written a Cobol program since the 1980s, and I am hopeful I never will. Still, Cobol had many significant advances.

1. It popularized the notion of program portability, in that a Cobol program was expected to run, nearly unchanged, on any machine with a Cobol compiler.

2. It popularized the notion of data portability, in that DISPLAY data (though not COMPUTATIONAL data) should be the same, and produce the same results, on machines of disparate architectures.

3. It popularized record data types.

4. It emphasized the idea of program readability, even though we would now (I hope) reject “pseudo-English” as a solution.

The fact that it fell (far!) short of these ideals should not blind us to Cobol's significant contribution to programming languages.

At least a dozen state unemployment systems still run on this sixty-one-year-old language, including ones that help administer funds of a billion dollars or more in California, Colorado, and New Jersey. When the deluge of unemployment claims hit, the havoc it seemed to wreak on COBOL systems was so widespread that many states apparently didn’t have enough programmers to repair the damage; the governor of New Jersey even publicly pleaded for the help of volunteers who knew the language.

The article broadly claims that COBOL is viewed dismissively compared to other languages of similar vintage like C or FORTRAN, because unlike those latter it did not come out of a "research-oriented context". However, as a matter of fact, neither C nor FORTRAN came out of academia; much like COBOL, they were developed for practical use as opposed to "research". ISTM that the perceived issues with COBOL must be explained in some other way.

The article dismisses the criticism against COBOL with an argument akin to "mathematicians use those funny symbols because they like to feel superior to everybody else."