## ADD 50 TO COBOL GIVING COBOL

For some inexplicable reason COBOL doesn't get much love from LtU. But COBOL turns 50 some time this year and we owe a tip of the hat to this venerable language behind so many large institutions.

The Guardian understands.

According to Michael Coughlan, a lecturer at the University of Limerick, one of Cobol's perceived drawbacks is its verbosity. But he reckons that's also one of its strengths. "It's not just a write-only language," he says. "You can come back years later and understand the code."

This opinion is shared by Mike Gilpin, of Forrester, who is an ex-Cobol programmer. "Cobol is one of the few languages written in the last 50 years that's readable and understandable," he says. And he's scathing about the readability of more fashionable languages, such as PHP and Java: "Modern programming languages are ridiculously hard to understand."

There you have it! More readable than PHP and Java. A ringing endorsement for the next half century.

## Comment viewing options

### For some inexplicable reason

For some inexplicable reason COBOL doesn't get much love from LtU.

Ha!

### Rename?

In honor of this semi-centennial, I propose that we rename the site "ISAM the Ultimate" for the remainder of the year.

### isam the ultimate

...but only if we're willing to encode naturals as:

 01 Nat
88 zero VALUE 0
88 succ VALUE S(Nat)


and use MOVE CORRESPONDING style BEFORE-FINAL-WHEN-DELIMITED when doing the exercises in The Little COBOLer.

### Good one

Unfortunately that's not valid cobol; value clauses must be literals/constants. Oh God why is that still in my brain?!?!? Should've been replaced with BSG trivia by now....

### COBOL is sooo unintuitive

COBOL is sooo unintuitive lacking objects and what not...

### Intuitive for 7 years already

But they made COBOL intuitive when they added objects to the COBOL 2002 standard. There were OO COBOLs around before that, too, but I suppose they weren't standardized.

Interesting to note that the decision to add OO was made in the early 1990s. No-one can accuse COBOL of not being cutting-edge!

On the subject of readability, a similar argument is made in the Lisp world. I think the argument about being able to read the code years later has some validity. I rather enjoy finding ways to write terse expressions in Haskell, but when we're all programming in Charity or Coq++ in 10 years time, how hard is it going to be to read that old punctuation-ridden Haskell?

ADD A TO B GIVING C FTW!

### Intuitive for 7 years already

But they made COBOL intuitive when they added objects to the COBOL 2002 standard.

Shouldn't they have added local variables first?

### Heh

Reminds me of my first job. Fortunately I wasn't using Cobol, instead I was using Progress 4GL, but I still felt it was extremely frustrating. Progress strikes me as quite similar to PL/SQL, though I never have used the latter.

I could cope with the the verbosity of Progress. What annoyed me to no end was the utter lack of abstraction mechanisms, including a proper function call and return or parametrized subroutines. That's such a third generation concept, something that fourth generation languages have moved well beyond. :-P

My boss didn't understand the importance of all this. He was an ex-Cobol and RPG programmer, and thought Progress was the greatest thing since sliced bread. Admittedly, Progress probably is huge step up from these, but it hardly felt adequate.

The company had the (small) problem that the overall support costs grow quadratically with each additional customer; it is reasonably successful in it's niche, but can't possibly grow large, obviously.

### Not quite :-)

It was business-type software, they licensed a base package from somebody else, and had extensively customized it.

Moreover, if any given customer wanted their own customizations, then the boss would come up with a price, we'd make a copy of the files in question, and hammer out the customizations. The downside of this is that it becomes very time-consuming to make changes in the the base, as then you frequently have to update the customer-specific customizations as well. And upgrading the licensed base software literally takes years of effort.

However, the company did a good job keeping it's constant-factor development costs down: their development environment itself was largely custom, and I really didn't have to diddle with it hardly at all. It was integrated with CVS, and was a real joy to use.

Honestly, the environments I use for my own personal stuff aren't nearly as nice or streamlined. I need to put some more work into this though.

...seeing as Progress has had named parameters since 1990 (or earlier), a built-in GUI from 1993, functions, procedures and even a primitive Object System.

Are you sure you're not confusing this with MFG/Pro which was an enormously successful package written in an early version of Progress and which was regularly bought and customised as a product in its own right?

### Progress Functions

Well, forgive me, as the details of the language have largely faded from my mind. I was being (only slightly) hyperbolic with regard to functions: Progress has functions, but they are so extremely limited in what they are capable of abstracting that rarely I found them to be useful for the tasks at hand. Even at that time, I was definitely the type of programmer who would write a function readily, whenever I saw an opportune situation.

One of my biggest annoyances was the inability to abstract database queries. But I didn't find the language capable of abstracting much at all; as if functions were an afterthought. Parameters weren't really capable of passing anything other than the most basic of values.

I don't particularly recall parametrized procedures, per se. The company mostly used the "run" mechanism, where subroutines were a file, and that you called a file. Maybe this had some primitive parameter-passing mechanism, but I don't quite recall...

Edit: as for the base package, MFG/Pro sounds very plausible, but I honestly don't know.

### RPG is even more intuitive

RPG is even more intuitive than COBOL :-)

### Book for you

Ehud, here's the book for you: Java for RPG Programmers.

### This is like something out

This is like something out of the Twilight Zone...

These two, Coughlan and Gilpin, must be very frustrated software developers these days. I also doubt they've been in a situation where they needed to read and understand a 40 year old, 10 million line Cobol application. That's hard in any language but Cobol spaghetti is just beyond the pale.

I worked at a place years ago that translated a good sized COBOL program to C for its main product line. They occasionally referred back to the COBOL source and they always dreaded it because it wasn't very readable, at least to them. Perhaps it was because they did not know the language well. They occasionally referred to a book on it.

### One of the axioms of the

One of the axioms of the field is that you can write unreadable code in any language...

### As "standard cobol employs

As "standard cobol employs over 400 reserved keywords", I'm not going to blame the programmers on this one.

On the other hand, Haskell programmers just moved this to the user level. </snipe> Perhaps it's a problem with programming in general. What's the size of the vocabulary of a program relative to its size (for some notion of program size, e.g., man hours)?

### This is demonstrated by the

This is demonstrated by the overly verbose title of this article, as "ADD 50 TO COBOL" would be sufficient, less verbose and more readable :)

If Perl is a write-only language Cobol must a read-only language...

### The inescapable conclusion:

A Perl -> COBOL compiler is the obvious and necessary solution for reliable software engineering. I'll take my Turing Award in cash now, please.

### What are the PLT contributions of Cobol?

What are the PLT contributions of Cobol?

### This comes to mind

This comes to mind

Comment

### Oh, the memories!

My first programming job in university (though not my first programming job, which was in high school, writing in TRS-80 Basic of all things!) first involved Algol-68 (yay! and on a Burroughs 6800 machine to boot, which was a pure stack machine, with an instruction set which makes the JVM look sad) and then COBOL.

But the scary thing is that it involved a COBOL code-generator written in COBOL. I needed to add 'checkpointing' to the generated code, as that usually ran for about 26 hours, but the average up-time of the machine on which it ran was about 23 hours. Easy to see why that was a bit of an issue.

And tomorrow I'm off to the IFIP WG 2.11 meeting on... code generation! Apparently code generation has been in my head for 23 years or so.

Nevertheless, for ease of writing out report-generators that printed very nicely formatted financial information drawn from data in databases, COBOL was really very good. Writing code in other languages which gets columns justified as easily as one can in COBOL is rarely as easy. Luckily, I don't ever have to write such programs anymore!

One thing that changed over the years is the paradigmatic programs people use when comparing languages, which stem from the common programming tasks of the day.

Older languages, of the COBOL and PL/I era, were often sued to produce fixed column reports, and how they handled such tasks was an important factor (oh, ON ENDPAGE, how I loved thee...)

One gets the feeling sometimes that newer languages are not necessarily improvements in expressiveness etc. but rather merely adaptedness to current niches.

### poor COBOL programmers

Some years ago I saw at CeBit a man with a table hanging from his neck saying COBOL JOB WANTED or something similar. Well, he did not seem to catch up with the latest advances of programming languages. Last time the Y2K problem was an era for Cobol programmers. I guess it was their conspiracy :-)