Zum Inhalt springen

More COBOL Than Python: The Language That Refuses to Die

Zusammenfassung

COBOL, designed in 1959–1960 and built heavily on Grace Hopper’s FLOW-MATIC, still processes an estimated $3 trillion in daily commerce through financial transaction systems, banking infrastructure, and government benefit processing. The total volume of COBOL code in production — estimated at 800 billion to 1 trillion lines — exceeds the total amount of Python code written since Python’s creation in 1991. COBOL is not a curiosity; it is the invisible foundation of the world’s financial system, maintained by a diminishing and aging workforce with no clear plan for what happens when they retire.

Why COBOL Was Designed This Way

COBOL (Common Business Oriented Language) was designed by the CODASYL committee in 1959–1960 at the explicit direction of the US Department of Defense, which wanted a common programming language for business data processing that could run across different vendors’ hardware. The specification was written by CODASYL’s Short-Range Committee, but it drew most heavily on FLOW-MATIC, the English-like business language designed by Grace Hopper — a debt that earned her the informal title “grandmother of COBOL,” even though she did not sit on the committee that drafted the standard.

The key design choices that made COBOL dominant for business computing also made it verbose and, to modern programmers, alien:

  • English-like syntax: ADD SALES-TAX TO PURCHASE-PRICE GIVING TOTAL-PRICE was considered more readable by business users than arithmetic notation. The goal was that non-programmers could read and audit COBOL code.
  • Fixed-precision decimal arithmetic: COBOL performs arithmetic on decimal numbers, not binary floating-point. For financial calculations where 0.1 + 0.2 must equal exactly 0.3, this matters.
  • Record-oriented file handling: COBOL was designed for batch processing of sequential files on magnetic tape — the dominant storage model of 1960.
  • Division structure: Programs are divided into IDENTIFICATION, ENVIRONMENT, DATA, and PROCEDURE divisions, reflecting an era when different specialists handled different parts of a program.

The Scale of COBOL Deployment

The specific numbers are estimates — no one has counted all the COBOL code in existence — but industry surveys consistently produce staggering figures:

  • Approximately 95% of ATM swipes involve a COBOL program somewhere in the transaction chain.
  • US federal agencies process an estimated $22 trillion per year in financial transactions through COBOL systems.
  • The New York Stock Exchange and major clearinghouses run COBOL systems for trade settlement.
  • The IRS processes tax returns through COBOL systems that have been in continuous operation since the 1960s.

When COVID-19 unemployment claims overwhelmed state systems in 2020, New Jersey Governor Phil Murphy made a public appeal for COBOL programmers to help modernize legacy unemployment insurance systems that were receiving more traffic than they had been designed for. The systems had been running without major modification for decades.

The Workforce Problem

The COBOL programmer workforce is concentrated in workers who learned the language in the 1970s and 1980s. The median age of a working COBOL programmer is estimated at over 50. As this cohort retires, the organizations that depend on COBOL systems face a choice: replace the systems (expensive, risky, potentially decades-long projects) or train new programmers in a language that is not taught at universities and carries no career prestige.

Several high-profile modernization attempts have failed catastrophically. The UK’s National Air Traffic Services attempted a COBOL replacement in the 1990s that was eventually cancelled. The California Department of Motor Vehicles attempted a $44 million COBOL modernization project in the 1990s that failed. The FBI’s Virtual Case File system, a modernization project for a system with COBOL components, was abandoned in 2005 after spending $170 million. These failures increased organizations’ reluctance to attempt replacements and deepened their dependence on aging systems.

Why Python Doesn’t Displace It

Python is the dominant language for new development in data science, AI, and scripting. It has more active developers writing new code than any other language. But Python does not replace COBOL because COBOL’s installed base is not in new systems — it is in systems that have been running continuously, correctly, for 40–60 years. A COBOL payroll system that has processed payroll without error for thirty years represents decades of accumulated business logic. Replacing it with Python requires finding all that logic, understanding it (often without adequate documentation), implementing it correctly in the new system, and trusting the replacement enough to switch off the system that has worked for a generation.

The economics rarely favor replacement. The cost of migration is certain and immediate; the benefit is long-term and uncertain. So COBOL runs on. The Rise of High-Level Languages brought many successors to COBOL’s era — none of them successfully displaced the specific niche COBOL occupies.

📚 Sources