I love spending my time investigating cool features of languages, even if I won't have a chance to use them anytime soon, but keep hearing only bad things about Cobol, but I'm sure it must of had some nice features for it to become as important as it did. So what would be some good features that could be learnt from Cobol?
An ability to write formulas in less concise manner. For example:
ADD YEARS TO AGE.
MULTIPLY PRICE BY QUANTITY GIVING COST.
SUBTRACT DISCOUNT FROM COST GIVING FINAL-COST.
Is it an advantage or disadvantage? depends on how you look at it...
It's very easy to learn. I have only written two COBOL programs in my life (to unpack COBOL ISAM files into a different format) and I learned all I needed to know in order to do it, with the help of a book,in an afternoon.
Oh, and it will impress on your brain the correct spelling of the word "environment".
True fixed-point variables and math. So, for 15 dollars and 75 cents your internal representation was the binary digits 1, 5, 7, and 5. This was an exact representation versus the standard floating point approximation. Also, all addition and subtraction on that fixed-point variable was also fixed-point.
The Report Writer extension was very good at generating reports and handling headers, footers, page breaks, section breaks, and just about anything having to do with generating reports.
The Sort/Merge extension was also very, very good. With the variety of allowable constructs you could simply sort/merge, or you could process sort input records before the sort or sort output after the sort. For example, feed the input records directly to sort but then use Report Writer on the sorted records without having to manage an intermediate sorted file in your code. Very nice.
What it did well, it did very well. It is just that most of the time, what it did well isn't exactly what you need.
Longevity. The language I first learned in 1975 can be used to consume web services today.
Also, COBOL has a feature I hear people asking for every day. Given two records having fields of with the same names, you can do:
MOVE CORRESPONDING SOURCE-RECORD TO DESTINATION-RECORD.
and it will move the fields with the same name from one to the other, doing conversions as necessary. The lack of a feature like this is one of the barriers in the way of people adopting Data Transfer Objects for return from web services - you have to write the code to do the above, by hand, or use code generation.
I think there may have been an ADD CORRESPONDING
as well, but I'm not sure. The memory begins to go, after a while...
Output format is part of the variable declaration. It's very business-oriented.
In COBOL, a variable declaration consists of a line in the DATA DIVISION that contains the following items:
* A level number. * A data-name or identifier. * A Picture clause.
A starting value may be assigned to a variable by means of an extension to the PICTURE clause called the VALUE clause.
Some examples:
01 GrossPay PIC 9(5)V99 VALUE ZEROS. 01 NetPay PIC 9(5)V99 VALUE ZEROS. 01 CustomerName PIC X(20) VALUE SPACES. 01 CustDiscount PIC V99 VALUE .25.
The data structuring features are about as good as it gets for fixed length fields.
ALTER is downright mind bending. Maybe not good for use in production code, but fun to play with. Basically, it lets you change what statements follow what other statements (insert GOTOs) at runtime.
Support for packed decimal for accurate math;
Built in indexed files/sorting;
Mature compilers;
It's a bit verbose, but it gets the job done.
1). Easy to learn. 2). The syntax is more english like and hence easy to understand the program logic even for beginers.
MOVE CORRESPONDING
Say you had 2 classes in C#, which had some fields in common, for example, class A has Name, Age, and Sex, plus some other fields... class B has those same 3 fields, plus some others of its own. The only way to copy the fields would be:
a.Name = b.Name;
a.Age = b.Age;
a.Sex = b.Sex;
In COBOL, you just write:
MOVE CORRESPONDING A TO B
It also has an interesting feature when declaring variables... at the place of declaration of the variable, you can also declare some possible values of the variable and label them with booleans. You can use
IF [boolean_label]
instead of
IF [variable] IS [value]
which is especially nice if the values are not particularly meaningful (i.e. magic numbers or even magic strings)... those magic values only appear in the declaration of the variable and are nicely labeled with what they mean.
You can even set the variable to one of these values with:
SET [boolean_label] TO TRUE
Another advantage... if you are programming on a mainframe, you can pretty much be sure that COBOL will be available... not true for any other languages. It's kind of like the C of the mainframe.
Oh, how could I forget...
Instead of:
if ((a == 3) || (a == 4) || (a == 10))
write:
IF A IS 3 OR 4 OR 10
Instead of:
if ((a == 3) || (a < b))
write:
IF A IS 3 OR LESS THAN B
Instead of:
if ((a >= 3) && (a <= 10))
write:
IF A IS BETWEEN 3 AND 10
COBOL is great for formatting output. An output field that looks like:
TOTAL-PAY PIC $$$,$$$.99
would print the $ right next to the value. It would print up to $99,999.99. If the value was only $150, it would print $150.00. Also, there is usually a COBOL function that would convert that amount to words - "ONE HUNDRED FIFTY DOLLARS AND NO CENTS"
It is 50 years old this year, but Cobol is still a key player in behind-the-scenes business software (Guardian)
You can also redefine records to allow processing of text files of multiple record types.
01 my-address-record.
02 my-record-type pic x.
02 my-street pic x(20).
02 my-city pic x(20).
02 my-state pic x(2).
02 my-zip pic x(5).
02 filler pic x(3).
01 my-comments-record redefines my-address-record.
02 filler pic x.
02 my-comments pic x(50).
01 my-automobiles redefines my-address-record.
02 filler pic x.
02 year pic 9(4).
02 make pic x(20).
02 model pic x(20).
02 filler pic x(6).
--code--
if my-record-type = 'a'
... process address
else if my-record-type = 'b'
... process comments
else if my-record-type = 'c'
... process automobiles.
The folks at Sun (now Oracle) will probably get mad at me, but FORTRAN and COBOL were the first attempts at write once, run anywhere languages. IBM added extensions to the COBOL language that pretty much nullified the attempt for COBOL.
Before COBOL and FORTRAN, computer languages were machine specific. Computers were so expensive that it was cheaper to rewrite the code each time you upgraded the computer. IBM realized in the late 1950's that creating and maintaining a consistent computer architecture would save customers money (and increase the market for computer systems). That's why IBM developed the 360 series of computers.
In the same manner, customers realized that rewriting software for each new machine was getting too expensive. IBM developed the beginnings of FORTRAN, while Grace Hopper and the federal government drove the development of COBOL. Which explains why IBM added all those proprietary extensions to COBOL. The federal government involvement also explains why COBOL is such a verbose language.