The Common Business Oriented Language, designed by a team lead by Grace Hopper. Designed to be read by managers. Its unverified origin is explained at Cobol Causes Brain Damage.
I don't think Grace Hopper was the "official" team leader. However, her earlier work on language design had a lot of influence on COBOL. The way some of the members describe it is basically the committee couldn't agree on anything (massive ego battles), ran out of time, and then fell back on Grace's earlier work as a basis for the language because it had generally worked, was liked, and they needed to produce something fast because they had squandered their time on those ego battles. Nothing like a deadline to inject reality into idealists.
I believe COBOL was originally designed to be easier to read than assembly language. That's pretty much all you can say for it...
Don't forget the B in COBOL.
See also its spiritual successor Abap Language, which is basically COBOL for SAP R/3 systems.
A COBOL programmer can say things like:
DIVIDE TOTAL BY NUMBER GIVING PRO-RATA REMAINDER RESIDUE.
Cobol also allowed things like
SORT PEOPLE-FILE ON KEY SSN.
A COBOL program is divided into divisions, sections, paragraphs and sentences. The sentence above may not be valid, as COBOL has getting on for a thousand keywords, one or more of which I may have used as, well, not variables exactly, as names above.
COBOL assumes hierarchical data records. This fitted most of data of the time: Unit Record Systems, Tabulators, Punch Cards, Line Printers, Magnetic Tapes, etc..
It was and is one of the few languages that had exact fixed point decimal arithmetic on big numbers. This is useful for a type of data called money. The B in COBOL. For example, if you computed WAGES you could get the dollars and cents to count how many bills and coin of each denomination would be needed to fill the weekly pay packets. No division was needed, you just had CENTS OF WAGES.
Interestingly, there is some attempt to isolate a COBOL program from its environment, placing all the system specific details in one division at the top. Not bad for the 50's.
The most fun construct in COBOL is the ALTER verb. COBOL has something like the "computed goto" of FORTRAN. Older dialects have no notion of a procedure or function, all the flow of control is done with named paragraphs and gotos. Anyway, ALTER lets you change, at runtime, where the branches of a goto go to. As Charles Weir pointed out, one could use this to implement polymorphism. If you had a lot of time on your hands.
FORTRAN has (or had) a similar thing called assigned GOTO. -- John Fletcher
By 1970, if not earlier, any section or paragraph (or sequence of sections or paragraphs) could be executed as a subprogram with the PERFORM verb. This also provided structured loops:
PERFORM WAGE-CALCULATION UNTIL END-OF-FILE. PERFORM FACTORIAL-MULTIPLICATION VARYING MULT FROM 2 BY 1 UNTIL MULT > 100.
COBOL is still a force in the world, so much so that when I was an unemployable fresh graduate the British employment service thought that having a City And Guilds certificate in COBOL programming would help my job prospects enough for them to pay for me to get one.
Cobol Language's market share is the envy, aspiration and Holy Grail of all Fourth Generation Language vendors.
-- Matt Rickard
Syntax for old COBOL at
http://www.csci.csusb.edu/dick/samples/cobol.syntax.html
The readableness of things like
PRINT PIC CR********9V.99.
was always debatable.
-- Dick Botting
Not if you were working at a financial institute of the time. Leading with asterisks was done to ensure no alteration of counter-checks. Seems pretty obvious in that light, print amount with all leading spaces filled with '*', float a '+' or '-' in front.
-- CHergerThomann
Format templating is a good thing in my opinion. I don't know of a better alternative. I agree that maybe COBOL's templating symbol choices were not always the best, but at least it had a solid set.
There's speculation on What The Ytwok Drivers that the inflexibility of COBOL, and in particular, the absence of abstract data types (or some other mechanism for information hiding/encapsulation) aggravated the Y2K problem. Had COBOL these features, moving from 2 to 4 digits dates should have been much easier.
Many developers said that it was often to save disk, memory space, and card space, which was very expensive at the dawn of computing. ADT's wouldn't help there. Also, standard punched cards had 80 characters. If you went over that, then you had to deal with double stacks. Many interviewed said they would have happily used 4-digit years if not for the hardware-related issues.
And if pigs had wings, they could fly. In those days, compiler writers were still fighting to show that assembler wasn't the Ultimate Language, external storage was magtape and punched cards, and no one had things like ADTs. (Though perhaps it could be faked in Lisp, which is approximately the same age as Cobol.) -- David Wolff.
It would seem that the poster on WTYD was not suggesting that COBOL was deficient by not having features that weren't available at the time, but rather that because we all do use ADTs and encapsulation and such these days (right?) any future such problem would be easier to fix. Not that Y2K was such a problem anyway, it turns out. Judge the porcine aviation factor of todays "best practice" for yourself.
COBOL made me think of Code As Poetry before I knew much about the Perl Language. -- Nick Bensema Or perhaps, code-as-folktale? I present, "The Common Business-Oriented Goldilocks":
See also Cobol Fallacy, a lesson which Apple Script did not learn.
A Cobol grammar generated from the official Cobol standard is available (in a rather readable format) at
Another Cobol grammar, which was actually used for the purpose of Reverse Engineering Cobol Legacy Code, is available at
Apparently, COBOL is now available for the Microsoft .NET framework. See Other Dot Net Languages.
There's also OO-COBOL - see home.swbell.net . Cobol++? Should be called "POSTINCREMENT COBOL BY 1 GIVING COBOL"!
COBOL Standards:
1968 = "COBOL Classic" ;->
1974
1985 = Adds structured if/else/end-if, perform/end-perform, etc.
1989 addendum = "added intrinsic functions, such as COSINE and TANGENT"
1993 addendum = "corrected errors and ambiguities"
1995 = "Object Oriented" COBOL
2002 = "includes object-oriented features, locale support, UNICODE support and data validation."
objectz.com = an interview with Don Schricker
2008 = planned next version
I've been tutoring a university student who's taking an intro programming course, and the instruction language is Java Language. One day she was asking me some questions about why Java is the way it is, and I forwarded a link to Java Is The New Cobol and some COBOL example program for reference. She came back a few minutes later and asked, "um, so why don't people just use that?" Since this question required an hour of answer or none at all, I changed the subject. Still, it's interesting how the verbosity of COBOL makes it somehow seem less dated than it is.
COBOL User Groups (COBUG)
A COBOL programming portal that is a one-stop resource for the COBOL community where you will find references to user groups, compilers, forums, jobs, and other COBOL programming resources.
See original on c2.com