Every legacy-language writeup on this site eventually has to answer some version of the question 'is it dead?' For PL/I, that's the wrong question to lead with, because PL/I was never trying to just survive. It was designed to win, specifically against COBOL, on COBOL's own turf. By almost every measure people usually reach for, it lost. And yet it is, right now, in 2026, shipping compiler releases specifically tuned for hardware that came out last year. Both of those things are true at the same time, and the gap between them tells you more about PL/I than another timeline of where it came from.
Round One: The Bet
IBM's committee work on PL/I began in 1963, ran through formal specification work in 1964, and produced a first shipping compiler in 1966. The target was not one language, it was two at once: FORTRAN's numeric strength for scientific work, and COBOL's record-oriented data handling for business, fused into a single language IBM hoped would make picking a language by industry unnecessary. That framing shows up directly in how software architect Doug Meil, writing a retrospective for Communications of the ACM, summarized the ambition.
“PL/I stands for Programming Language 1, and its aim was to be the Highlander of programming languages: There would be no need for version 2, 3, or 4 if everything went to plan.”
Doug Meil, "Lessons from PL/I: A Most Ambitious Programming Language," Communications of the ACM
That framing matters more than it sounds like it should. A language pitched as one reasonable option among several only has to win some new projects to count as a success. A language pitched as the last one anyone will ever need has to be good enough that abandoning whatever a customer already has running costs less than staying put. PL/I set itself the second, much harder bar, and it set it against two languages that had no intention of holding still.
It's also worth being precise about how unusual that bet was for the era. Other languages of the 1960s picked a lane: FORTRAN for numerical computing, COBOL for business records, LISP for symbolic processing, ALGOL for describing algorithms cleanly. Each one optimized hard for its own audience and largely left the others alone. PL/I instead tried to be the single implementation detail underneath two audiences that had different type systems in mind, different ideas about what a runtime error should do, and, it turned out, different tolerances for how much syntax they were willing to learn. Designing one language competent at both jobs was the easy half of the problem. Convincing two separate customer bases to trust it with production work was the half that actually sank it.
Round Two: Timing Beat Design
The problem was never that PL/I's design was weak. It's that both of its targets kept moving. FORTRAN 66 became the first ANSI-standardized version of FORTRAN in the same year PL/I's own compiler shipped, meaning PL/I was trying to make a target obsolete that was busy calcifying into an industry standard at that exact moment. COBOL was worse: it had already moved through COBOL-60 and COBOL-61 and kept advancing through COBOL-65, COBOL-68, and COBOL-74, each revision adding exactly the kind of business-data feature PL/I was supposed to make unnecessary. Meil's account puts the structural problem plainly.
“PL/I was not just a development effort, it was also in effect a system conversion.”
Doug Meil, "Lessons from PL/I: A Most Ambitious Programming Language," Communications of the ACM
That's the real cost PL/I was asking customers to absorb, and it had nothing to do with syntax. A shop already running COBOL in production wasn't being asked to learn a new language for a new project. It was being asked to replace a working, debugged system with a new one that did the same job, written in a language most of the staff hadn't used yet. By 1970, per Meil's account, COBOL had already become the most widely used programming language in the world. Once that was true, the pitch flipped from 'switch to something better' to 'replace a system that already works,' and that pitch has never once been an easy sell in enterprise software, in any decade.
Round Three: What the Scoreboard Says Fifty Years On
That's not a ranking that says PL/I is thriving. It's a ranking that says PL/I lost the specific fight it was built for, decisively enough that most working programmers today will go a whole career without touching a line of it. On the terms PL/I set for itself, being the default choice for new development, COBOL won and PL/I didn't. That part isn't really in dispute, and no amount of reframing changes it.
That's the scale PL/I was up against, and it's also the scale that explains why PL/I's loss didn't come with an off switch. Nobody rips $65 million of annual mainframe budget out and replaces it with something else on a whim, whichever language it's written in. The same institutional inertia that kept COBOL in place for fifty years past its supposed expiration date applies just as hard to the PL/I shops sitting next door to it. Losing the popularity contest and getting decommissioned are two completely different events, and only one of them has actually happened to PL/I.
The Line Item That Doesn't Fit the 'Dead Language' Story
IBM does not spend engineering budget re-tuning a compiler's code generation for hardware that shipped in 2025 unless there is a production workload on the other end of it worth the investment. A CPU-usage reduction like that isn't a marketing number aimed at a museum piece, it's a number aimed at whoever is currently paying for MIPS on a mainframe running PL/I in production right now and deciding whether recompiling under the new release is worth the project. TIOBE measures how many people are searching for and writing about a language today. It says close to nothing about how much still depends on the code that's already there, still running, still generating an invoice every month. Enterprise PL/I 6.2 also added an ARCH(15) option that unlocks z17-specific optimizations without touching a single line of source, plus new vector instructions for inline hex and base64 handling and support for 16-byte integers, all shipped for a language that, by TIOBE's own numbers, almost nobody is starting new projects in.
The Rematch Nobody Predicted: Leaving the Mainframe Entirely
The more interesting recent development in PL/I's story isn't happening on the mainframe at all. Raincode, a compiler vendor best known for its COBOL work, lists PL/I compiler integration alongside its COBOL and ASM370 compilers directly in Microsoft's own Azure Architecture Center reference architecture for rehosting mainframe applications, generating fully managed, thread-safe .NET code and running it on Azure Kubernetes Service or virtual machines. That's a genuinely different modernization path than the usual 'rewrite it in Java or C#' story: the PL/I doesn't get replaced, it gets recompiled. The business logic stays exactly what it was; only the hardware underneath it changes. Microsoft's own architecture documentation lists native EBCDIC support at compile time and runtime and integration with RACF and Top Secret identity systems through Active Directory extensions, which is a fairly good signal that this path is aimed at the same regulated, security-conscious institutions that adopted PL/I for core banking in the first place, not at hobbyists.
See PL/I modernization paths →What This Means If You're the One Maintaining It
None of this history changes the practical calculus for someone staring at a PL/I codebase today. It just changes which fear is the right one to have. The fear that PL/I is a dead end nobody supports anymore doesn't hold up against a compiler that just picked up z17 optimization and a 35% CPU-usage improvement. The fear that PL/I is thriving and worth building an entire new career around doesn't hold up against a TIOBE ranking in the high twenties. The realistic read is narrower than either extreme: PL/I is a stable, still-vendor-supported dependency inside a small number of large, specific institutions, mostly European banks and airlines, that have already decided the cost of keeping it running is lower than the cost and risk of replacing it. That's not a language in decline and it's not a language on the rise. It's a language that reached equilibrium decades ago and simply hasn't moved.
So, Who Actually Won?
If the question is which language new projects reach for, COBOL won, and it wasn't especially close. If the question is which language IBM is still actively funding compiler engineering hours for, the honest answer is both, and for the same underlying reason: neither one's actual customer base has finished migrating off it, five decades on. PL/I's loss was real. It just turned out to be a loss with a multi-decade tail rather than a stopped clock. The banks and airlines that adopted it in the 1970s and 1980s never migrated over to COBOL afterward; they just stopped being the ones whose story got told in English-language coverage of mainframe computing.
- PL/I set out to make FORTRAN and COBOL unnecessary; it succeeded against neither.
- COBOL's continuous evolution through COBOL-60 to COBOL-74, happening at the same time PL/I was trying to replace it, was as much a factor in the outcome as any design choice PL/I itself made.
- By TIOBE's August 2026 index, PL/I sits at #27 with a 0.67% rating, a fair measure of new interest and a poor measure of production dependency.
- IBM shipped Enterprise PL/I 6.2 with z17 support in 2025 and reports CPU savings of up to 35% for recompiled workloads, evidence of a live paying customer base, not a museum exhibit.
- Vendors are now offering PL/I applications a way off the mainframe entirely, compiling straight to .NET and Azure, rather than requiring a full rewrite.