A recent discussion over at the Open-Cobol mailing list have brought up some nice gems.

My generation learned COBOL not from textbooks but from vendor manuals
and also a set of tutorials in the form of programmed texts called the “IBM green books”
(they had green covers). Programming was an apprenticeship business back then.
We learned from each other.

Comparing the world of today’s corporate programming, of which I am a part, to the world of yesterday’s, from my memories of visiting my mother’s workplace, I can really relate to this description. I would compare this to any person studying a profession and practice, but not being actually familiar with any of the tools and application they’ll actually use. These days, of course, basic to advanced courses are required in any computer-based tool, from OS and Office suites, to the tools-of-trade and assisting applications.

> > I would state that a simple Hello World Program in COBOL has become MUCH simpler
> > than his example. We no long are required to have all those sections or even the
> > preceding line numbers.
> Yeah, on the opencobol.org forum (and in the soon to be unveiled FAQ), hello world is as
> short as:
> program-id.hello.procedure division.display "Hello World!".

There was a language in my youth called APL whose fan base revelled in creating one line
programs. I hope COBOL and its fan base has not been reduced to that level.
An important and unique feature of COBOL is that it was designed to be read as well as written.
It is intended to be a self-documenting language. While recent versions have strayed far from that
original concept the thought of reducing a sample program to one line is a violation of one of the key
features that makes COBOL different from other languages. Just because you can do it doesn’t mean
you should do it.

COBOL was conceived as a language that will have a syntax that will allow non-programmers to be able to read it, and for the programmers to easily translate the non-programmers pseudo-code’s logic to a program. This resulted with PERFORM READ-FROM-FILE UNTIL END-OF-FILE and EVALUATE USER-INPUT
WHEN NEXT-RECORD ADD 1 TO RECORD-NUMBER GIVING TOTAL-RECORDS
But it also caused the language to become encumbered with the actual semantics, where any action requires a long description, maintained in several parts of the code simultaneously. Over the years, attempts were made to include more advanced features, while, on the other hand, reduce the amount of text needed to be used. It would seem that Open-COBOL have dropped everything but the actual commands, giving a slim version of COBOL, which might do it the justice it needs (if only it was compiled to byte-code rather than to C).

Another interesting element here, is the writer’s reference to one-liners and APL. This is a well known argument against Perl’s supposed unreadability, based on its one-liners, obfuscation and “programming golf” challenges. I, however believe that these, and other traits of the language are a virtue. A programming language with an English-like verbosity, that has an ability to use the shortest programming form, the “one-liner” as an expression method. Apart from the constrains of style and practice, this, is the true strength of Perl, the ultimate freedom of expression in computer programming form.