Musings on COBOL

[pozorvlak]

In a world such as this one, filled with war, famine, impending ecological collapse and Celtic fans, it really ought to take more to horrify me than this. But I guess I'm shallow that way.

Before diving into the actual text, let's just take a step back and consider the implications: the University of Limerick was teaching their "introduction to programming" course in COBOL, in 2002 (and as far as I can see, still are).

[Non-geeks: COBOL is the Common Business-Oriented Language, an ancient language used on dinosaur mainframes with about as much style and joie de vivre as the name implies. The Jargon File notes that in hacker circles its name is "synonymous with evil", and Edsger Dijkstra famously commented that "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense."]

I originally started by quoting individual lines of the linked page (and this one: Can A Java Programmer Be Transitioned To Cobol?), but this post quickly got far too long, so I'll attempt to summarise the more eyebrow-raising bits. The authors claim

• As of 1997, 80% of the 300 billion or so lines of code in the world were in COBOL. As of 1999, 50% of all new mission-critical software development in business was still being done in COBOL.
• 1,000,000 lines of code is common for a COBOL app, and 6,000,000 lines is not considered unusual at many shops.
• 30 year or more lifespans for COBOL apps are quite common.
• A major contributor to COBOL's maintainability is something often considered a major weakness: its verbosity.
• Another contributor is also usually considered a weakness: its lack of features. Until 1997, there were no user-defined types, no user-defined functions (! - though there is, I think, an equivalent of Pascal's procedures), and no block structure (!!!). This "encourages a simple straightforward programming style".
• COBOL comes with a standard library that's good for batch processing of records containing financial information - something common in business environments, but often left out of libraries for other languages. In fact, to quote the second article, "It follows that extensive business use of computers depends on how successfully and easily computers can be made to handle records" and "Java programmers busy themselves with writing routines that are supplied with Cobol". This standard library is (perforce) written in some other language, such as Fortran.
• The three fundamental concepts of programming are sequence, selection, and iteration.
• "A program is a collection of statements written in a language the computer understands. A computer executes program statements one after another in sequence until it reaches the end of the program unless some statement in the program alters the order of execution."

Now, taking this at face value, we all ought to be petitioning COBOL programmers for the secrets of their success: 6 million lines is huge (it's about the size of the Linux kernel), and I've seen projects less than 2% of that size degenerate into unmaintainable balls of mud. But these guys, much derided though they may be, have managed to build programs that size and keep them going, adjusting to new requirements and adding new features, for over thirty years, and don't think it exceptional. Clearly we should let go of any idea that succinctness is power, and realise that verbosity is maintainability.

But I have my suspicions: such as, how much do those 6 million lines actually do? And how hard can it be to write payroll systems, anyway? Obviously quite hard, since the XP guys didn't manage it, but why? And are those 6 million line COBOL apps actually maintainable and understandable, or are they just big balls of mud held together with spit and prayers, only working at all because they don't actually do very much?

I don't know: not actually speaking COBOL, I'm ill-equipped to judge whether it's actually an evil language, or an overlooked gem. Overlooked gems are certainly possible - Lisp and APL are both about that age, and I think they both have things to teach the rest of the programming community. Then again, my cousin did a lot of COBOL maintenance in the run-up to Y2K, and was quite glad to see the back of it.

Something seems clear to me, though: there's a huge class of users that have been largely ignored by language designers, namely business users. COBOL was designed back in 1960 as a short-term interoperability measure: the only serious attempt I'm aware of to capture that application niche since has been Visual Basic, which was specced out, waterfall-style, by someone with less than six months' experience (not quite, but I love hyperbole - read the article for the truth). Is this really the best we can do? Some kind of domain-specific language for records and finance, based on more modern principles, ought to be possible.

For another interesting (and more informed) perspective, see markdominus' perl.com article Perl meets COBOL, about the culture clash when he taught an introductory Perl workshop to a group of experienced COBOL programmers.

Anyway, I'm glad to see that there's finally an open-source COBOL compiler - several previous attempts died on the vine. If there are over 200 billion lines of the stuff, I'd like it to be able to run on Linux :-) Speaking of which, does anyone know the state of VB operability on Linux? Gnome Basic is dead, and the Mono page says nothing about support for pre-.NET versions of VB. Can Wine handle this stuff? There's a huge dark mass of VB-and-Access code out there that many small businesses rely on: without being able to run it, world domination will probably stay beyond our grasp.

Comments

[necaris.livejournal.com]

Well, there's GAMBAS... and I believe OO.o has some kind of Basic support built in?

[pozorvlak.livejournal.com]

Are you citing them as examples of languages-for-biz-types, or as solutions to the VB porting problem? Because GAMBAS is intentionally incompatible with VB (he chose the incompatible design goal of making a language that was actually good :-) ). I don't know if OO.o can import macros in Word/Excel/PowerPoint documents, but I know it can't import Access databases or macros - the train of thought that led to this article was "I bet we could implement r_e_mercia's app as an Access macro... I could do that in OO.o... best check I can export to Access... what?!?! How are we going to get world domination at this rate? Speaking of which, I wonder if the open-source COBOL situation is as bad as it was when I last looked... let's Google for 'COBOL'... oh dear God, my eyes!"

[necaris.livejournal.com]

Ah, didn't know that about GAMBAS, though I'd guessed about OpenOffice :-)

Just to remind myself, I fired up Access at work, opened the Visual Basic editor and had a nice <shudder> moment... nothing compared to COBOL though!