views:

983

answers:

16

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?

+13  A: 

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

Koistya Navin
Please cite any quotations - thanks!
Andrew Hare
"Ripped from Wikipedia"I know how strange it feels to reference Wikipedia. It just doesn't sound good :)
Peter Perháč
Besides being utter nonsense the Wikipedia quote says twice "it has been said" without reference. I already knew Wikipedia can be rather mediocre, but is this the gossip column or what?
stevenvh
COMPUTE FINAL-COST = (COST * QUANTITY) - DISCOUNT. That's a little more real world and recognizable.
tonyriddle
Is this answer supposed to be funny, or what? It seems to be a snarky jab at COBOL, but maybe I'm missing something.
Sean McMillan
I looked at the Wikipedia article and didn't see anything like that remaining, so i cut the quote.
RCIX
+2  A: 

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

anon
+8  A: 

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.

+5  A: 

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

John Saunders
+4  A: 

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.
Thomas L Holaday
I have also seen these PICTURE clauses used to actually define file formats... even for use by languages other than COBOL
JoelFan
+3  A: 

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.

Glomek
+4  A: 

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.

EvilTeach
+2  A: 

1). Easy to learn. 2). The syntax is more english like and hence easy to understand the program logic even for beginers.

kishore
+3  A: 
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
JoelFan
You could do that in C# with interface and method call.
Silvercode
........ how? ........
JoelFan
+3  A: 

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
JoelFan
I don't understand this one :/
Robert Gould
http://home.swbell.net/mck9/cobol/style/88.html
JoelFan
A: 

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.

JoelFan
+4  A: 

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
JoelFan
the problem with these cool conditions is that they are a devil to parse... last time I checked there is no way to compile cobol using parser generator... it all has to be hand crafted
JoelFan
+1  A: 

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"

Cathy Sullivan
I wrote one of those functions. Not only in COBOL but in DEC's failed attempt at merging COBOL and BASIC (think COBOL without all the words) called DIBOL (DIgital's Business Oriented Language)
David
+1  A: 

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.
tonyriddle
I'm sorry, but COBOL in lower-case just doesn't look right :-)
Alistair Ward
+1  A: 

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.

Gilbert Le Blanc