The problem in the late 1950s
Businesses and governments were buying large computers to handle payroll, inventory, billing and other record keeping. The tasks were different from scientific calculation. They involved many records, lots of reading and writing, formatted reports and modest arithmetic.
Programs were written for each manufacturer’s machine, often in assembly language or in a language specific to one vendor. That tied an organization to one supplier, and moving to new hardware meant rewriting everything. People involved in purchasing computers, including in the United States defense establishment, saw this as expensive and wanted a common approach.
A committee effort
In 1959, representatives from government, universities and computer makers met to discuss a common business language. A working group known as CODASYL (the Conference on Data Systems Languages) was formed to produce a specification. The name COBOL, short for Common Business-Oriented Language, was chosen, and early specifications appeared around 1960.
COBOL did not appear from nothing. Earlier languages for business data, including FLOW-MATIC, a language associated with Grace Hopper’s team, had already tried to use English-like words for data processing. Other company projects also contributed ideas. As with many “firsts” in computing, it is more accurate to describe COBOL as a pooled effort than as one person’s invention, and Hopper’s role is sometimes overstated in popular stories. She was an influential advocate of the approach and served as a technical adviser, but a committee wrote the language.
What made it different
COBOL was designed around records, files and reports rather than formulas. A few features stand out:
- Readable statements. Instructions looked like short English sentences, such as adding one value to another or moving a value into a field. The hope was that managers and auditors could follow the logic even if they did not write code.
- Data descriptions. Programs separated a description of the data (fields, lengths, formats) from the instructions that used it. This suited fixed-format files stored on tape or cards.
- Decimal arithmetic. Money calculations generally need exact decimal results, and COBOL supports that style of arithmetic, which matters for accounting.
- Portability goals. The same program was meant to run on machines from different makers with few changes.
This approach was well suited to mainframe computers, which processed large batches of records overnight. A typical job read a master file, applied the day’s transactions and wrote a new file and a printed report.
Standardization and adoption
For a language to be shared, compilers had to be written for each machine. Large customers, including government agencies, pushed suppliers to provide COBOL compilers, which encouraged vendors to support it. National and international standards followed over the years, with later revisions adding structured programming features and, eventually, object-oriented extensions.
In practice, vendors also added their own extras, so perfect portability was never achieved. Still, COBOL made it much easier to move skilled staff and programs between systems than earlier approaches had. Over the following decades it became extremely common in banking, insurance, government and other large organizations, an important part of what we now call business computing.
Criticism
COBOL has been criticized from early on. Its wordiness meant even simple operations took many lines, and some computer scientists felt English-like syntax created a false sense of clarity, since the logic of a program can be complicated no matter how the words are chosen. Language designers who preferred concise notation, or who valued the then-emerging ideas of structured programming, often found it unappealing. University courses tended to favor other languages.
The readability goal itself is debated. Programs that look like English can still be hard to understand, particularly when decades of edits have layered on exceptions. Experience varies, and it is wise to be cautious about claims, positive or negative, that treat the language as inherently good or bad.
Why it persisted
A great deal of business logic written in the 1960s through the 1980s remained in use because it worked and replacing it was risky and costly. Organizations tend to rewrite such systems only when necessary. Programs were updated, wrapped with newer interfaces or connected to databases, including later relational databases, rather than discarded.
This longevity attracted attention at a few points. During the Year 2000 problem, fears about date handling in older systems drew public interest to old code, much of it in COBOL. Later, news stories about aging government systems also raised the question of how many programmers still understand them. Reliable numbers about how much COBOL remains in use are hard to find, so estimates quoted in the press should be treated carefully.
What it shows about language design
COBOL illustrates a theme found throughout programming languages: a language reflects the needs of its main users. Scientists wanted formulas, businesses wanted records and reports, and each community shaped the notation accordingly. It also shows that decisions made for institutional reasons, such as standardization led by large buyers, can keep a technology in service for far longer than its designers expected.