COBOL
In May 1959, the Pentagon hosted a meeting in Washington that would transform business computing for decades to come. Charles A. Phillips, head of the Data Systems Research Staff, gathered about fifty people: military personnel, civil servants, consultants, and engineers from the largest computer manufacturers. Each manufacturer at the time had its own language and its own machines. A program written for an IBM wouldn’t run on a UNIVAC. How could efforts be pooled in a sector where administrative applications were beginning to proliferate?
This meeting gave birth to CODASYL, a committee tasked with examining computer languages. A smaller group, the “short-term committee,” received the mission of analyzing the strengths and weaknesses of existing compilers, primarily AIMACO (its military variant), FLOW-MATIC (Grace Hopper’s creation at Remington-Rand), and COMTRAN (a highly theoretical IBM project).
No one expected this committee to produce a new language. Yet in November 1959, six people locked themselves away for two weeks and emerged with the specifications for a language they named COBOL: Common Business Oriented Language. This document, finalized in April 1960, went far beyond a simple synthesis of existing languages.
COBOL’s technical design was based on its structure of four divisions: IDENTIFICATION for program information, ENVIRONMENT to describe the execution environment, DATA to structure data, and PROCEDURE for instructions. The syntax resembled English sentences, making the code readable even for non-specialists. Variable names could contain up to 30 characters, an innovation that allowed the use of clear, understandable names rather than illegible abbreviations.
The moment of truth came on December 6 and 7, 1960, during a public demonstration: the same COBOL program executed correctly on two radically different machines, an RCA 501 and a UNIVAC II. For the first time, code portability became reality.
COBOL’s early years were marked by several evolutions: COBOL-61, COBOL-61 Extended, then COBOL-65. ANSI standardization arrived in 1968, followed by other standards in 1974 and 1985. Backward compatibility, ensuring that old programs would continue to function, was a remarkable characteristic that was maintained.
The U.S. government required that any computer sold or leased to government agencies must have a COBOL compiler, and this was one of COBOL’s success factors. This decision forced manufacturers to develop their own compilers, propelling COBOL to the status of an essential standard in business computing.
One might question the extraordinary longevity of this language born as a temporary solution, which several factors explain. First, its relative simplicity made it accessible to non-academic programmers who formed the bulk of corporate IT teams. Its readability facilitated application maintenance. Its orientation toward administrative data processing corresponded perfectly to the needs of the service sector.
Facing the Y2K bug, the world discovered with astonishment the omnipresence of COBOL in the workings of the economy. Staggering estimates showed that of the 300 billion lines of code in production worldwide in 1997, approximately 240 billion were written in COBOL. More than 95% of financial and insurance data passed through these programs.
Against all apparent logic, COBOL crossed the Y2K threshold without losing its importance. In 1999, more than 50% of new critical applications were still being developed in this language, despite the emergence of Java. Projections for 2004-2005 estimated that 15% of new applications (5 billion lines) would be in COBOL, while 80% of deployed applications would constitute extensions to existing COBOL programs.
This unexpected resilience stems from the language’s technical characteristics: no pointers, elementary data types, detailed description of files and print outputs. These limitations, which might seem handicapping for scientific applications, are actually assets for business applications by reducing the risk of catastrophic errors.
In our world obsessed with perpetual innovation, sometimes simplicity and stability prevail over sophistication. A language deemed obsolete by computer scientists since the 1970s continues to run the world’s financial systems in the 21st century, demonstrating that theoretical elegance is not always a guarantee of practical relevance.