COBOL has been “dead” for so long, my grandpa wrote about it

Original Article ↗ Hacker News Discussion ↗

COBOL’s reputation as a “dead” language is contrasted with its ongoing role at the core of banks, governments, airlines, and other critical systems, where decades-old code still processes huge transaction volumes with remarkable stability. Commenters explore why these systems persist—mainframe reliability, extreme migration risk, and the loss of institutional business knowledge encoded only in code—despite dwindling expertise, mixed salary realities, and widespread developer disdain for legacy environments. There is cautious interest in tools and LLM-based projects that translate or modernize COBOL, but many argue the real bottleneck is understanding embedded business rules, not merely changing syntax or platforms.

Scope and longevity of COBOL

  • COBOL is “dead” only in the sense that few greenfield systems are started in it; it still underpins many banking, government, airline, utility and enterprise systems.
  • Mainframes and COBOL compilers are modern and actively maintained (z/OS, new Telum processors, LTS compilers). Legacy systems may be old in logic, not in hardware.
  • Many argue COBOL and mainframes will persist at least into mid‑century; some call it “undead” rather than dead.

Reliability, environment, and patching

  • “Never failed” claims are attributed less to the language and more to mainframe architecture: stable ABIs, batch‑oriented workloads, reserved I/O/CPU, redundancy, and conservative change management.
  • OS and runtimes are patched regularly; COBOL programs often run unchanged for decades.
  • Comparisons with Python/Java highlight that COBOL changes slowly and gets very long‑term support, whereas modern ecosystems move faster and break more often.

Migration, modernization, and risk

  • Rewrites are seen as extremely risky because:
    • Business rules accumulated over decades live only in mainframe code and a few experts’ heads.
    • Systems mix COBOL with assembler, VSAM, custom IPC, and deeply intertwined data models.
  • Many institutions wrap mainframes with web services or middleware instead of replacing them.
  • There is active work on migration tools and emulation: COBOL‑to‑Java/COBOL‑to‑cloud platforms, GCC/LLVM frontends, containerized mainframe workloads, and open‑source stacks (e.g., GnuCOBOL, SuperBOL). Success and maintainability remain open questions.

Jobs, pay, and skills

  • Reports on compensation conflict: some mention very high consultant bill rates; others see only modest premiums over mainstream languages.
  • Big value is often domain and platform knowledge (CICS, JCL, DB2, z/OS) rather than COBOL syntax.
  • Access to real mainframes is a key barrier; language alone is easy to learn.
  • Some suggest COBOL work is stable but “boring”; others see it as a good hedge against hype cycles.

Language design, 4GLs, and “dead” languages

  • Thread debates “language generations” and notes many 4GLs and RAD tools (dBase, FoxPro, ABAP, etc.) have faded or narrowed while COBOL, Fortran, and others persist.
  • Several argue that most mainstream languages never truly die; they enter long maintenance tails and their ideas live on elsewhere.

LLMs and legacy code

  • LLMs are already used to explain and partially translate COBOL, RPG, and similar code; results around 80–90% accuracy are cited.
  • Many stress LLMs don’t remove the need for understanding complex business rules; prompts are effectively another DSL without a formal spec.