Lambda the Ultimate

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

...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.

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....

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!

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

Shouldn't they have added local variables first?

...support costs grow quadratically with each additional customer...

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?

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 than COBOL :-)

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

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

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

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 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...

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

This comes to mind

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.