100 years of Grace Hopper

For most people who work in IT, the programming language COBOL is as dead as the dodo.

Yet Grace Hopper, the woman credited with establishing COBOL (Common Business-Oriented Language) as the language of business, would be pleased to know that 100 years after her birth, the language still underpins many applications that keep modern businesses going.

This Saturday is the centennial of Grace Hopper, who was born on December 9, 1906. Often referred to as "the mother of COBOL," her contribution to the theory and practice of programming is commonly appreciated as enormous. She is credited, among other achievements, with being the first person to develop a compiled program in an age when computers worked by running programs that were interpreted one line at a time.

Credit: IEEE

Grace Hopper

Hopper got her first degree in mathematics and physics at Yale University and her master's in the same subjects. She taught at Vassar College before joining the U.S. Naval Reserve in 1943 and working on one of the earliest electronic calculators, the Harvard Mark 1. She was in her element working as, effectively, one of the world's first computer programmers--and she was very good at it. (For a comprehensive bio, read Wikipedia's entry on Hopper.)

She continued working on the Harvard Mark 1 and Mark 2 before moving to another company in 1949 to work on the Univac 1, where she developed the compiler.

After returning to the Navy, she worked on validating software written in the new language, COBOL, with which her name would be indelibly associated. Her greatest achievement in computing was here, as she gradually evolved the idea that software should be easy to use instead of being a long string of mathematical functions and notations.

From that point came the principle that programs should be easy enough for businesspeople to use and understand; in principle, COBOL is for the businessperson, not the scientist.

"COBOL is still in use today and plays a part in those programs that keep businesses running," said Julian Dobbins, director of product management at Micro Focus, one of the key companies still developing for the language. "(Analyst firm) Gartner reckons that 75 percent of business transactions are still done in COBOL."

Banks and other financial institutions are chiefly accountable for this high figure. Systems that run banking transactions, such as those used by ATMs, were largely written years ago and are still running. They are economical and efficient, and COBOL code is easy to fix if these go wrong, so, the argument goes, why change them?

As for new applications, there is little, if any, work still done in COBOL, with more modern languages, such as C++, having replaced it.

So why use COBOL today? "As a programming language, it was designed on sound principles," Dobbins said. "And you can take modern principles like Web services and service-oriented architectures (SOA), and find that it offers really very easy deployment."

But even Dobbins, who has used COBOL himself since his college days, admits that COBOL is stuck with a poor image. "I remember chatting with a programmer at a conference and talking about using COBOL in object-oriented apps," Dobbins recalled. "He said, 'Why would I want to do that? It would be like turbocharging an oxcart.' My response was to say that the world does not rely on oxcarts."

Dobbins sticks with the view that the world does rely on COBOL. Dobbins believes that the principles that make COBOL a sound language to this day are those first established by Grace Hopper and that 100 years after her birth, the world should continue to be grateful for them.

Hopper died January 1, 1992.

Colin Barker reported for ZDNet UK in London.

[RussHolsclaw]

COBOL Rationale still valid

I've been in this business for 40 years, and although I've never used COBOL, it's only because I've never worked in accounting applications. The reason Grace Hopper invented COBOL was to create a language that could be understood by anyone that could read English. Since business programs are the embodiment of accounting practices, they should, of course, be readable by an auditor.

In the light of Enron and other accounting fiascos involving conflicts of interest with auditors, this reasoning is just as valid as ever, if not moreso. The family of "C"-based langauges, on the other hand, are more subject to writing programs with sneaky secondary effects (such as are produced by ++ and -- operators, logical operation short-circuiting, and other stunts), not to mention the lack of proper decimal arithmetic support that supports rounding properly.

One problem today is that there are too many programming snobs who are ignorant of original reasoning behind decisions made before they were born.

[aabcdefghij987654321]

About COBOL

There are things that COBOL was designed to do well that other languages have never yet done as cleanly and easily as COBOL. COBOL's bad image is based more on marketing of newer languages than a lack of capability in COBOL.

I don't program in COBOL these days but I wouldn't have a problem with going back.

[fafafooey]

The "Cobol is readable" is mostly myth

I programmed in Cobol for many years, and it is/was a good language for programming business apps. Over the years, we eventually replaced all Cobol I/O with embedded SQL and a GUI interface using Acucobol. Using the apps, you couldn't tell them from VB or other "modern" language.

Combined with embedded SQL and a GUI screen painter, it was a lot like a 4GL.

But I've always heard about the "readability" of Cobol by non-programmers, but I've never seen it actually happen. Even though Cobol is fairly verbose and uses English commands, you still need to do "programmer stuff" eventually and that's still difficult for non-programmers to understand. And programers tend to get lazy with adding comments, giving variables meaningful, readable names, and using syntax shortcuts, so the programs become less and less readable.

[rtball]

I agree completely

Cobol may be easier to read than some other languages but it is still a technical computer language. The basic code might be simple but add in some MQ calls, a little SQL and some CICS and it gets confusing quickly.

[HandGlad2]

Opposite view

Only the lazy (you perhaps?) went the route of less readable names. I started using simpler names and as I got more experience I made longer and much more descriptive names and was more likely to include longer and more descriptive comments. It helped that we went from coding forms and keypunches to terminals with decent editors.

In any case, a good coding style applied consistently through a program could make it a lot easier to follow, something that's still true for most of the popular languages of today.

You obviously came too late to compare it to languages like Fortran and RPG.

[rtball]

Dead as a Dodo?

I have to disagree that little or no development is being done in Cobol today.

There certainly is less new development than there was 10 years ago but existing systems are still being enhanced for new requirements. If Gartner is correct and 75% of business transactions are done in Cobol then someone has to be maintaining those systems because they don't always work the way they are supposed to do.

Currently I'm coding a Medicare D enhancement to the billing system of a major fortune 500 company. All the code is Cobol.

Additionally I agree with the first comment and the statement:

"There are things that COBOL was designed to do well that other languages have never yet done as cleanly and easily as COBOL. COBOL's bad image is based more on marketing of newer languages than a lack of capability in COBOL. "

This is clearly evident in reporting with Cobol. A report is very easy to create and print in 133 green bar format in Cobol. Can the same be said of creating reports in the newer languages?

[lawrencewinkler]

Cobol Suffers from Poor Architecture

I haven't written Cobol in years, and I do not know if there has
been significant improvements in the language, but the code I
have written (usually by taking existing code, copying it, then
making changes), and code that I've seen suffer greatly from
poor architecture.

The first is global working storage. This is probably Cobol's
worst architectural defect. Is there a new Cobol standard that
allows private storage? Of course, correction here requires ease
of creating internal procedures/functions supporting parameter
passing, along with compile "type" checking, etc.

The second defect is the lack of a full-fledged procedures and
functions, accepting parameters and returning values in an
architecture that would allow unit testing of these individual
modules.

Finally, there is training of Cobol programmers, and managers.
The seemingly few improvements in the Cobol language that
have occurred (case statements, structured ifs) are infrequently
used, assuming the company has even bothered to upgrade to
the newest compilers supporting these features.

And old programs are likely not to be refactored and
rearchitected to make use of new and better features, assuming
the company has modified their strict coding standards, defined
and unchanged since 1965, to allow or require the use of the
new structures.

[fafafooey]

Those things aren't easy to drop into Cobol

Cobol does still have a global working storage, and that is still where variables must be defined, so that makes it difficult to drop in functions and procedures with local variables into the standard.

There have been some changes to provide similar capabilities however. Using "contained subprograms", you can simulate functions and procedures and even local variables.

For example:

identification division.
program-id. main-program.
data division.
working-storage section.
01 local-to-main-program pic x(10).
01 global-to-all-programs pic 9 is global.
procedure division.
move "abc" to local-to-main-program.
call "my-procedure" using local-to-main-program.
exit program.
identification division.
program-id. my-procedure.
data division.
01 local-to-my-procedure pic x(5).
linkage section.
01 passed-param pic x(10).
procedure division using passed-param.
... do something with passed-param.
... move 1 to global-to-all-programs.
exit program.
end-program my-procedure.
end-program main-program.

In this example, "my-procedure" works like a procedure (or it could act like a function and return values) in a language like C or VB. It has local storage that is not seen by the main program. But you can still have globals seen by all programs. These "contained" programs can all be embedded within one file, and their scope would then be local to the main program in that file.

There are also new object oriented features in the 2002 standard, which a few vendors have implemented, but I don't see those being used heavily.

Your point is well taken about whether or not any of these features will be used or code refactored (or "rewritten" - the word we used before the term "refactored" became the buzzword).

It's unlikely that maintenance programmers are going to shoehorn these constructs into existing programs - they will likely not have the time or authority to make such structural changes. And it's unlikely that massive rewrites of existing Cobol code will be done.

[DryHeatDave]

The answer -

"Global" is a relative term. architectual re-engineering is frequently at the module level, to ecapsulate a specific business function, or a group of functions. With the rise of SOA & Legacy Re-engineering, COBOL provides great support for DB2 on Big Iron.

Furthermore, Enterprise COBOL provides new functionality like eternal storage, allowing data to be passed, simply by passing a pointer - should be familiar to OO developers :-) Then there's the build in XML parser/gener. And YES - you can write OO COBOL !

With products such as Websphere MQ, it's easy to create loosely coupled applications. I'm currently creating an app for CICS TX series, DB2 & Websphere App Server (all on Z/OS - NOT my choice, but it is possible).

Now that CICS & more recently IMS can handle SOAP XML, what was it that COBOL couldn't do ?

I've been writing and more recently designing/architecting COBOL, Z/OS & Websphere for the last 20 years & can say that COBOL has a very valid role to play.

[qwerty75]

Many "dead" languages are still going strong.

COBOL is one, Fortran is another that not only has a massive installed base, but is still used in very critical systems like nuclear plants. IIRC, Fortran was the first high level language, and is still relevant today.

The problem is that there is a lot of hype in the software industry and much of it is unfounded(*cough c# and .net). It is really sad that hype rules over even technically savvy people. Many Algol and Simula derivatives have done well(C, C++, Java), despite there many flaws, but some have fallen away in spite of being technically superior(Eiffel for one)

[Ian Joyner]

Languages

>>>Many Algol and Simula derivatives have done well(C, C++,
Java), despite there many flaws, but some have fallen away in
spite of being technically superior(Eiffel for one)<<<

Glad to see you mention Eiffel, but it is hardly dead and still
undergoes much development and library building (http://
www.eiffel.com/). It has generics done right (vs Java's belated
and backward compatible generics and C++'s attrocious
templates, and myriad gotchas) multiple inheritance done right,
garbage collection done right.

It's good to see Grace Hopper get recognition though - COBOL
was a great achievement at the time. It should now be thought
of as a scripting language for the specific purpose of business
record processing. Of course it has flaws when used in other
domains vs other general purpose languages.

[tedk7]

Cobol is horrific

Cobol is terrible and that's all there is to it.

If I was responsible for it, I'd try to keep that fact to myself. Yuck.