I think of scala in this context. I think that scala is basically dead at this point in the way that COBOL was framed in the article. Yes, there are still many businesses/services that have critical components written in scala but current mindshare has cratered for new projects. I only single out scala because I have spent a lot of time with it and have seen it go through the hype cycle (in 2012-14 it seemed like I was constantly seeing doing $X in scala pieces on HN and I almost never see it referenced here anymore). It's probably a natural and inevitable phenomenon (and a bit of a shame because scala did get some things right that other mainstream languages still have not).
I know a couple of engineering teams at Apple that are working on new projects in Scala, while also maintaining some legacy systems. Some of these projects are quite critical to the company’s ecosystem, e.g. test systems. I’ve spoken with several engineers who helped create these systems years ago; they’re all now in senior management positions. Some still stand by the technology choices made back then, while others are more open when given a chance to reflect. The general consensus is that if Kotlin had been available at the time, or if Swift had been a viable option for back-end services, they definitely wouldn’t have chosen Scala for those projects.
You know, one of these days I really need to sit down and play with some of these "legacy" languages, like Fortran or COBOL or Ada or APL; languages that have certainly fallen out of popularity but are still used in some critical places.
It does make me wonder about millions and millions of lines of Java out there; Java has more or less eaten the enterprise space (for better or worse), but is there any reason to think that in 30-40 years the only people writing Java will be retirees maintaining old banking systems?
This is what people miss about COBOL. It's not like people are compiling COBOL and running it on Linux on an x86 box. They are running it on legacy operating systems (and hardware) which provide a different set of underlying services. It's a whole different planet.
The mainframe is turning into a middleware layer running on Enterprise Linux. We've containerized the mainframe at this point, and I mean that directly - eg. Running jcl, multiple CICS regions, all in COBOL that originated on z/OS is now running in k8s on amd64.
I hope you're right, but many comments here on HN suggest their experience with mainframes is very different. z/OS and its predecessors provided so many services completely transparently to the application that a mainframe to modernity migration is doomed to fail unless it can completely emulate (or design around) the capabilities provided by the OS and other subsystems.
Even ignoring the needs of the super high end customers like banks (eg, cpus in lockstep for redundancy), being able to write your app and just k ow that inter node message passing is guaranteed, storage io is guaranteed, failover and transaction processing is guaranteed, just raises the bar for any contender.
K8s is wonderful. Can it make all the above happen? Well, yes, given effort. If I'm the CTO of an airline, do I want to shell out money to make it happen, risk it blowing up in my face, or should I just pay IBM to keep the lights on, kick the can down the road, and divert precious capital to something with a more obvious ROI? I think their "no disasters on my watch/self preservation" instinct kicks in, and I can't really blame them.
There is a major drawback to this approach -- you need to have somebody who knows what they are doing. Total deal breaker in most of the places that have this problem in the first place.
"you need to have somebody who knows what they are doing"
That applies everywhere.
Your parent comment has managed to stuff a mainframe in a container and suddenly, hardware is no longer an issue. COBOL is well documented too so all good and so too will be the OS they are emulating. I used to look after a System 36 and I remember a creaking book shelf.
The code base may have some issues but it will be well battle tested due to age. Its COBOL so it is legible and understandable, even by the cool kids.
If you lack the skills to engage with something then, yes, there will be snags. If you are prepared to read specs, manuals and have some reasonable programing aptitude and so on then you will be golden. No need for geniuses, just conscientious hard workers.
ha yes. There is actually a pretty cool product that is made by a division of Rocket Software named "AMC", it takes a COBOL app running on an IBM system and deploys it to a whole set of services on AWS. There are some smart dudes at that shop.
Fair, I guess the list was “languages that I know were popular at one point but I don’t know anyone really using now”.
Ada definitely does seem pretty cool from the little bit I have read about it. I’m not sure why it’s fallen by the wayside in favor of C and its derivatives.
Ada was mandated by the DoD for a bit. My understanding is that, in practice, this involved making a half-hearted effort in Ada, failing and then applying for a variance to not use Ada.
Often, I'm sure, but there are large code bases in Ada still. It's a shame, it looks like a really great language I would love. But it's a chicken and egg problem. If only Mozilla had decided on Ada instead of Rust! :-)
I actually met a programmer who worked on military jets. According to her, Ada is only used anymore for the older jets that were already programmed in it, and she worked in C++.
This. Nobody wants to have the COBOL problem again, so the developer hiring money follows the programming language popularity market (with a certain regulatory approved laf ofc)
Nah not really. People just started replacing COBOL with java and employers are wise enough to hire people who are 30-40 years minimum from retirement.
It can also be upgraded in smaller chunks and finding enough developers for the tool is an important metric corporate is looking at.
If anything, banks are actively optimizing for developer experience to make sure 60% of new hires don’t run away in the first year. If anything, banks are better at navigating those kind of structural risks, they were just slow on undertaking such risks exist.
If you have an episode of existential anxiety because of dat AI eating mijn job, getting a union job in a bank is a way to hedge this particular risk.
> ...employers are wise enough to hire people who are 30-40 years minimum from retirement.
Um oh yeah, the reason we're hiring 20-year-olds is because we want to ensure we have lifelong support for the new system we're writing. Not because they're cheaper, they're still idealistic and naive, they'll work long hours for foosball tables and stacks, or anything like that...
In a place where you can imagine having COBOL, working long hours is frown upon and being idealistic beyond personal integrity isn't a good quality either. Not saying such places aren't cheap, as of course they are. Being cheap is their exact point.
Article starts mentioning 4GL's - a term I have not heard in a long, long time.
COBOL's promise was that it was human-like text, so we wouldn't need programmers anymore. A lot like "low code" platforms, and now LLM generated code.
The problem is that the average person doesn't know how to explain & solve a problem in sufficient detail to get a working solution. When you get down to breaking down that problem... you become a programmer.
The main lesson of COBOL is that it isn't the computer interface/language that necessitates a programmer.
> COBOL's promise was that it was human-like text, so we wouldn't need programmers anymore. A lot like "low code" platforms, and now LLM generated code.
The more things change, the more they are the same.
This blows my mind, since it seems like a fairly low level/terse language compared to more modern domain specific languages.
But in some sense they were dead right... since (I assume) that what "programming" meant at the time was being able to write raw machine code by hand on paper, and have it work - something few people can or need to do nowadays
> This blows my mind, since it seems like a fairly low level/terse language compared to more modern domain specific languages.
I have heard others and myself describe COBOL in many ways, most involving creative expletive phraseology which would make a sailor blush, but "low level/terse language" is a new one to me.
> But in some sense they were dead right... since (I assume) that what "programming" meant at the time was being able to write raw machine code by hand on paper ...
Vision 4GL. Like VB but cross platform and with a horribly unstable IDE which would corrupt the source code. (Which was in some kind of binary format not amenable to source control.)
For what it's worth, I'm still actively looking for a COBOL speaker for the 2025 Carolina Code Conference. Been wanting to get a COBOL talk for a while, especially with GnuCOBOL's recent update.
"I don't know what the language of the year 2000 will look like, but I know it will be called Fortran." —Tony Hoare
COBOL is alive in that it keeps changing from era to era, to the point modern COBOL looks rather little like the 1950s COBOL everyone instinctively thinks about when they heard the term. It's as if we were still programming in Algol because Java had been called Algol-94 or something.
Maybe I'm in a minority, but I genuinely dislike conditions placed afterwards.
They feel great to type out when you're in the flow, but coming back and reading them grates on my nerves. Seeing the condition first means I load a logical branch into my mental context. Seeing the condition after means I have to rewrite the context of what I just read to become part of a logical branch, and now the flow of reading is broken.
I mean, if you squint your eyes a bit, that could be SQL! So even if it's not COBOL, there's people out there writing in a vaguely english business programming language.
So you spotted that? I have no proof or links to share, but I've always thought SQL was inspired by, or at least made to not look out of place next to COBOL. I recall COBOL coding card layout interpreted a flag on punch cards at the char column where top-level picture clauses needed to start specifically for designating a line as SQL for static embedded SQL preprocessing.
I think it’s more that computers at the time didn’t all have lowercase characters. Consider that even C and C++ supported trigraph/digraph compatibility chars until something like last year (and IBM still complained…):
C is much older than Unicode, so it's not that surprising that some systems are still using https://en.wikipedia.org/wiki/ISO/IEC_646 and replacing some reserved punctuation (e.g., curly braces) with their country's accented letters.
The nice thing about a vaguely English like language is that your average LLM is going to do a better job of making sense of it. Because it can leverage its learnings from the entire training set, not just the code-specific portion of it.
I've used o365 copilot to analyze a COBOL app I had source code to, and it was great at explaining how the code worked. Made writing an interface to it a breeze with some sample code and I swear I am not a COBOL person, I'm just the Linux guy trying to help a buddy out...
It also does a reasonable job of generating working COBOL. I had to fix up just a few errors in the data definitions as the llm generated badly sized data members, but it was pretty smooth. Much smoother than my experiences with llm's and Python. What a crap shoot Python is with llm's...
A great thing about being a programmer is getting to complain about the crappy requirements you have to work with. SQL, on the other hand, is not a program - it’s a precise specification of the result you want, in a format that lets the database engine write the “program” for you. Thus, writing SQL helps you appreciate the struggle to achieve good requirements, and there is a chance you will develop empathy for those cursed to write them.
I am managing an ERP system implemented / went live in 2016. It's working on modern P10 hardware, which was released in 2021. The ERP system is continually updated by the vendor and customized by the client.
Even for COBOL running on an actual mainframe, which I think most HNers would think of 1970s dinosaur, most of the actual machines in production would be pretty new. IBM z16 was launched in 2022.
So they are "legacy systems" in the sense they're not written on a javascript framework which was launched last week, running on lambda instances in AWS :). But they are not "OLD" systems, as such.
Almost certainly yes. The "legacy systems" are likely running on versions of the mainframe with long-term support contracts, whose vendors are committed to providing newer compilers with support for newer versions of the specification as necessary.
As always, these discussions will depend on your definition of "dead" and "alive".
If we can call a technology dead once no new business is built on it, then I think we can safely call COBOL dead (and the IBM 390x aka Z/OS platform along with it, for which "COBOL" is usually a proxy).
But if we say that anything still being used in production is not dead, then of course COBOL is alive and significantly more alive than many other things which are younger than it.
But this shouldn't really be taken as a positive point for COBOL or the mainframe ecosystem. It's simply a fact of life that organizations tend to stick with the first thing that works, and for the types of entities involved in the first wave of digitalization (e.g. governments, banks, airlines) that was usually an IBM mainframe along with the software that runs on it.
> we can call a technology dead once no new business is built on it
You don’t suppose any bank - or other large financial institution - might have standardised on Cobol for their core business flows/processes? In which case a new business-unit or “internal startup” team (e.g. a new category of insurance product) might very-well have some part written in Cobol so it integrates with the rest of the bank - or at very-least might be built-on-top of the org’s existing Cobol-running infrastructure (i.e. Not written in Cobol, but still runs on Z/OS because there’s no budget for buying new commodity x86 racks and the people to manage and run them).
Sure, I know for a fact that what you're describing exists. That's not really what I mean by new business being built on it. That's a case of a very large and old business already being so locked into the mainframe ecosystem for their core systems that anything new they try to do ends up needing some kind of integration system with the legacy system.
What I mean is that nobody starts a business today and says "Ok, we need an IBM mainframe running DB2 and we'll have a bunch of COBOL, ReXX, and PL/I programs for handling our business logic".
A touching article! I have enjoyed similar times with my grandpa. On the topic of Cobol, I simply don't understand why people hate it so much. It has a shallow learning curve like Python, is self-documenting enough that one doesn't need to write a bunch of text, and is available on every conceivable architecture, with great performance. I personally wrote a payroll for an entire factory on a B1800 with 128K of memory and a 10MB hard disk! So what's to complain? In my mind, Java is deader than Cobol!
I think there’s something to that but there’s also a lot of selectivity there. Many of the same people who complained about COBOL because it was verbose adopted things like enterprise Java, so there’s more than a suggestion that this might be a less than completely objective assessment.
The bigger problem: COBOL was an open standard but none of the implementations were open source for ages (I haven’t looked at GNU COBOL in years, but I think this is no longer the case) so nobody was building new things or experience when they had to pay to get started.
Note: I'm getting some hate from others who think I would pick or prefer COBOL over a modern language. I wouldn't. I was making an outside-the-box "devil's advocate" objective observation. I just wanted to preface that here. Okay, the rest of my original comment remains below:
The irony is that we already had a memory safe and stable language in Cobol that was easier to read and understand than Rust. But, no one wants to use it so it is "dead" but it runs everything that made the modern age possible.
This is a weird take. Sure, plenty of cool/nice things from old languages (e.g. variable-sized stack frames in Ada) get lost, and some then get rediscovered by future languages, potentially wasting effort. And I don't know COBOL, so maybe you're actually making a good point.
But I find that hard to believe. Does COBOL really solve all the same problems Rust is intended to solve? Is it as performant? Can it interface with native code from other languages in the same way? Does it have a usable and sane package manager built on top of a module system that facilitates composability and backward compatibility? Does it have a way to describe the shape of data and errors as ergonomically as Rust's algebraic data types?
Genuinely curious: as I said, I don't know COBOL. I'd find it extremely surprising if the answers to all these questions are "yes," though. Just as there are reasons COBOL is still used, there are also (good) reasons new languages have been created.
Do they solve all the same problems? No, for example COBOL lacks a modern concept of concurrency within a single program. COBOL's concurrency features are based on task-level parallelism, which involves dividing a program into multiple tasks that can be executed concurrently.
Is it performant? Yes. COBOL is highly efficient particularly in handling large datasets and complex business logic and its compilers are optimized for reliability and speed.
Can it interface with native code? Yes.
Does it have a package manager? No.
Does it describe shape of data? No. Data structures in COBOL are defined using fixed-length records.
Note: I'm not a COBOL expert. I did learn it in college, though.
Imagine having a shell script being called from a cron job that writes data in a bunch of tab separated memory mapped files (memory mapping happens when you configure the thing), but you have more files than memory. And all the shell scripts call and include each other and have global variables too.
And that underpins most of the critical infrastructure in your country.
It's a bit odd to say these programs are comparable when the Cobol version isn't handling errors whereas the Rust program is (by panicking, but that's better than the silently wrong behavior of the Cobol one). Here's a runnable version of the above Cobol program (adding the necessary boilerplate); note that it prints "even" for an input of `abc` and "odd" for an input of `12`:
identification division.
program-id.
even-or-odd.
data division.
working-storage section.
01 num pic 9.
01 result pic x(4).
procedure division.
display 'Enter number: '
accept num
if function mod(num, 2) = 0
move 'even' to result
else
move 'odd' to result
end-if
display 'The number: ', result
stop run.
It's peculiar to call out Rust's syntax specifically when, like most other languages these days, is mostly C-like (though with a sprinkling of OCaml). And syntax aside, Rust and Cobol have wildly different goals, so "just use Cobol" doesn't suffice to obviate Rust's purpose for existing.
I guess my post is getting misread as "just use cobol" when it was more of a XKCD-like reflection; e.g. why did we all do that / keep doing that. We done did Cobol, and Rust. And, one is "dead" but not really and now here we are.
COMPUTE SIZE-NEEDED = LENGTH OF OBJ + LENGTH OF VARTAB * NUM-ELEMENTS
ALLOCATE SIZE-NEEDED CHARACTERS INITIALIZED RETURNING VPTR
SET ADDRESS OF VARGRP TO VPTR
MOVE NUM-ELEMENTS TO OBJ
MOVE BUFFER(1:SIZE-NEEDED) TO VARGRP
SET VPTR TO ADDRESS OF BUFFER
FREE VPTR
When you bank, COBOL (40% of online banks).
When you use the ATM, COBOL (95% of ATM transactions).
When you travel, COBOL (96% of airline ticket bookings).
Healthcare, COBOL.
Social Security, COBOL.
Point of Sale, COBOL.
IRS, COBOL.
Pension funds? COBOL. Hotel bookings? COBOL. Payroll programs? COBOL.
It is estimated that there is 800 billion lines of COBOL code in production systems in daily use. That is a bit more than 100 lines.
This was why Y2K genuinely scared everyone and was a very real problem. The only reason we can look back at it and laugh now is that an army of engineers sat down and rewrote it all in the nick of time.
Legacy code yeah, nobody's hitting File > New Project in COBOL
It's just that nobody understands how the systems work and they're ossified. Those systems are going to be emulated until our grandchildren take over because nobody can understand them well enough to craft a replacement. Juuuust up until an LLM rewrites them for us.
[edit] I mean those airlines systems are so old that they don't support special characters on names, passenger names are two fixed-length fields (first name, last name) and title and middle name just gets appended together.
So you get LASTNAME/FIRSTNAMEMIDDLENAMENTITLE on your bookings. And each of those fields is truncated lol.
and of course flight numbers are fixed at 4 digits, so we're running out of those.
That's not what makes something legacy. Legacy is something highly not advisable to change because it's both makes the business work and can't be easily changed because of complexity, loss of context, high blast radius or whatever. It's just there and you have to deal with it. If it wasn't complex, opaque and scary to touch it would not have been just another piece of something to be replaced and updated like the copyright date in the footer.
Oof, I've got good news and bad news for you.... they still are creating new code in it.
Yeah, there are fewer engineers in COBOL which is why it pays BIG bucks now. They desperately need someone to maintain that massive infrastructure that has been built up over 75 years that cannot be replaced easily or quickly.
Besides - standard COBOL is only "memory-safe" by way of not supporting dynamic memory allocation. Like, at all. Even strings are stored in fixed-length arrays.
"A ship in harbor is safe, but that is not what ships are built for."
Bizarre comment. No developer who should be allowed anywhere near a computer would ever consider choosing COBOL where Rust is appropriate or vice versa.
Well, I said it was ironic that we went out of our way to make a newer more complicated to read language that was memory safe when we already had a language that was simpler and readable that was safe.
I didn't say I wanted to code in it, though. I'd prefer in no particular order Kotlin, Python, Go, C++, Rust, Perl, C#, Java, Zig, etc. Anything really over COBOL myself. I'm part of the problem.
But, if I was hard up for money and wasn't getting nibbles for jobs? I could see getting into COBOL because there is a lot of money in it and always work available.
My statement stands though, we need to do better when designing the syntax of our languages. Cobol is disliked, yet simple and readable. What does that say about our new languages. How hated are our "new" language remnants going to be when few of us are longer around to maintain them 50 - 75 years from now? And, how easy are they going to be to pick up?
Addendum: I guess it won't matter if the singularity comes and just writes it all for us, of course. Then it will all just be machine code and we won't need these "only human" translation layers any longer.
Agreed. It's easy to have memory safety when you don't even support heap allocation. Now if OP had said "Java" or "C#" instead of "COBOL", they would've had a solid point. But the way Rust ensures memory safety without mandating GC while still allowing for complex allocation patterns can be said to be practically unfeasible for any of the usual "legacy" languages, with the notable exception of Ada.
Started my career doing Y2K stuff in 1998 and I still touch COBOL here and there today. I have a 10,000 line CICS program that runs every 30 seconds that I wrote in 2010. It has never failed since.
I don't understand these "never failed" comments. Without further context, it's meaningless. If I write a python script and never change anything in its environtment or inputs, it won't fail either. That's not specific to cobol.
Several years ago I briefly worked at a major telecommunications provider with services across the southern United States that ran Python 2.4 on their production provisioning servers. Worked just fine.
I understand the context to be that COBOL, as a DSL for batch processing, declares its .data and .bss segments, or the equivalents on host systems, statically in the DATA DIVISION and usually doesn't dynamically allocate memory. This, coupled with CPU, memory, and I/O bandwidth reservation from a job scheduler on an exclusive hot-swappable partition on a host (z/OS aka MVS) plus USVs, redundant disks/disk ports, and networks makes "never fail" much more a consequence and primary objective of mainframe architectures where COBOL workloads are usually run.
They absolutely are. Modern COBOL (even 25 year old COBOL) isn't running on ancient System360/370/390s or something, it's running on modern z/OS mainframes.
Technologies die very slowly once things of economic value depend on them. COBOL probably isn't used from new projects very often, but the economics of ditching it aren't very good either. It already works. Rewriting things that work is a great way to create new problems at great expense, so institutions are hesitant.
It's interesting reading articles from previous generations how they make it sound like people seem to remember what everyone in the tech industry said as if everyone mattered. I guess there weren't many people around in the industry back then.
Nowadays, even if someone is right about something and most people are doing it wrong, nobody will care to even discuss it unless the person making the statement is one of maybe 3 top influencers in that field.
I worked for a company in the late 1980s that started developing with a 4GL product (Dataflex) instead of COBOL. The article is right that COBOL has outlasted most (all?) of those 4GL solutions.
Looking back, COBOL would have been a better technical choice back then. Dataflex's metadata-based dynamic UI and report generation saved some simple, repetitive work, but much more effort was wasted working around its limitations.
almost all major financial institutions, utilities, gov't agencies, etc still rely heavily on COBOL today. If it ain't (extremely) broken, don't fix it?
COBOL developers are literally dying out which has made for a competitive market for remaining talent. I've heard of some large consultants charging over $500/hr to their clients for a COBOL developer!
I feel like every time COBOL is mentioned we get these stories about crazy high comp for COBOL developers, but anecdotally my aunt worked on COBOL projects in the mid 2010s and was paid a much more modest 45 $/hr. Good money for small town middle America where she lives, but nowhere close to what a decent JS dev can get.
Similar experience with a friend of mine. I feel like these high salaries only apply to people who habe worked at one of these companies for a looong time.
In COBOL implementations, it's generally not just knowledge of the language that makes you valuable, it's knowledge of the implementation at that particular organization. I'm not a COBOL dev myself, but I work with them, and part of the challenge is that everything is so uber-customized, tightly coupled, and there's 40+ years of undocumented business logic buried in the code.
It's like the old joke about the engineer being asked for an itemized bill:
"Chalk mark: $1. Knowing where to put it: $4,999."
I work for a major utility and they used to run everything on mainframe and cobol but that went away long before I started programming. My coworker is nearing retirement, around 30 years here, and he started on cobol and worked on transitioning off. He has some really fun stories but my point being, the tales of cobol prevalence are very exaggerated. Maybe some parts of finance are still using it, not my area.
I think the moat that COBOL developers have is not just their knowledge of the language, but knowledge of the mainframe programming and operating environment. Its just so alien to developers familiar with Windows/Linux, and there is really no way to get experience with the environment that I know of, other than to be employed doing it.
But yeah that stuff is never going away as far as I can tell. Its just too risky to rewrite those core systems and many a boondoggle has tried and failed.
About a decade ago I looked into moving some COBOL components off-mainframe (either as COBOL-on-Linux or a rewrite into Java, which itself is really COBOL Mk II at this point), and your point about the operating environment is one of the key elements, but not all of it; there's also the fact that the first big shift to automation, via mainframe assembler and COBOL, is when companies sacked a lot of the folks who knew how and why the pre-automation processes worked - that knowledge exists in the mainframe code and the heads of the people who work(ed) on it, and nowhere else. A rewrite or a replatform is very, very hard and risky as a result; the system is now defined by how the mainframe runs the processes, to a very large degree.
The third is that COBOL is only the tip of the iceberg. As soon as I spent time learning about the code I was being asked to look at, you get into decades of evolving programming practises. Modern COBOL is multithreaded, probably uses DB2 and relational datamodels. COBOL from thirty years ago is probably single-threaded, only runs right on high-clocked single-execution models, cuts down to hand-written s390 assembler regularly, and uses VSAM files with non-relational data. Older code still will be sharing data simply by banging it into memory regions for other code to read out of, because that's how you got performance back in the day.
Trying to identify how you'd pull a function out of that and move it off is somewhere between extremely difficult and impossible. It's usually so complicated and expensive it's easier to try and hire people who want to apprentice as mainframe programmers and keep the current codebase running.
> A rewrite or a replatform is very, very hard and risky as a result; the system is now defined by how the mainframe runs the processes, to a very large degree.
And that's why so many neo-banks/fintechs are eating the lunch of the established banks left and right, same for insurance. The "old guard" is unwilling to pay the costs of not just upgrading off of mainframes (aka the rewrite work itself)... but of changing their processes. That is where the real cost is at:
When you have 213.000 employees like BoA has and everyone needs to have at least 10 hours of training and 2 weeks until they're familiar with the new system enough to be fully productive, that's like 2 million man-hours just for training and 16 million hours in lost productivity, so assuming $50/h average salary it's around 900 million dollars in cost. Unfortunately for the dinosaurs, the demands of both the customers and (at least in Europe) regulatory agencies especially for real-time financial transfers just push the old mainframe stuff to limits, while at the same time banks don't want to cede more and more of that cake to Paypal and friends that charge quite the sum for (effectively) lending money to banks.
In contrast, all the newcomers start with greenfield IT, most likely some sort of more-or-less standard SAP. That one actually supports running unit and integration tests automatically, drastically reducing the chance of fuck-ups that might draw in unwanted regulatory attention.
BOA doesn't train the vast, vast majority of its workforce on mainframe systems these days. No one working in a branch or call center is looking at green screens anymore. The mainframe systems are simply used as back-ends connected through web services (yes, even in CICS!) or MQ Series and the like to web GUIs.
Source: worked there for many years, and built some of those integration systems.
Can't we just apply a bunch of correctness preserving translations towards a modern PL, perhaps aided by an LLM to keep the source as human readable as possible, while (I'm stressing this) preserving correctness?
But is the conversion maintainable by a human? I’ve seen Fortran to C translators that end up encoding state transition machines that are impossible to read.
You should take a look at my company. Heirloom Computing. Heirloom.cc We have migrated many mainframe application and millions of lines of cobol and pl1 into Java and deployed it into production on prem and into the cloud.
That seems like a myth to me. I actually looked up COBOL salaries and they were a bit higher (like 20%) but definitely not enough to make them tempting.
(Programming) languages take very long to "die". Most often you will get a long drawn out tail, and often parts of a language gets absorbed into other languages. Only the sages and etymologists will know where they have come from.
Old man reminiscence following, skip if you are not bored:
I worked with SNOBOL and I thought it will be a long term programming language.
I also want to think that I had some tiny, minuscule hand in dev of RIPscrip pre-Telegraphix, alas it went as the dodo bird.
I think I have forgotten more programming languages than I can count on my hands. Yet, I see them in some part every day in newer languages, "discovered" by some expert. "What has been will be again, what has been done will be done again; there is nothing new under the sun."
One language has come to my aid for the last 30-ish years Perl has came to my aid many times.
(I tell you a secret - in the deep deep bowels of a a very, very large, jungle named company, servers still have tiny Perl scripts running some core functions. I discovered this, when there was a problem that I had to deep dive into. I a recommendation to change to a hard-coded variable. The answer was "it will take two weeks". Why? Because no one knew what it will do or could read Perl. It was a 30 second job, including sdlc. Think xkcd Dependencyhttps://xkcd.com/2347/ )
Still doesn't beat Assembly, which will continue running on Voyager 1 even after the inevitable demise of our planet. Would survive the end of our solar system too.
Great story. There's something wicked personal in it, and it's very good. I reckon that this bloke's grandfather was an interesting bloke - cobol or no.
Frankly, in all these stories about COBOL programs being modified for Y2K and whatever... isn't COBOL a compiled language? What's really amazing is that all these legacy systems have buildable source code and the toolchain to build them with i.e. that that stuff hasn't suffered "bit rot" or other neglect.
Key components of the U.S. Internal Revenue Service tax processing code (e.g., the "Individual Master File" or IMF) are written in COBOL and IBM Assembly Language.
There is an ongoing effort to refactor as Java. This will ultimately take years and cost $100s of millions of dollars. There is still a small but shrinking team of graybeards who can actually maintain the code, which has to be reprogrammed every year to accommodate changes to tax code.
See, e.g., IRS IT Strategic Plan documents, publicly available.
The idea of programming language generations were based on paradigms of programming that never really caught on. The idea, roughly, is that 3GL are those languages where you specify how something is to be done, 4GL is where you specify what is to be done instead, and 5GL is you specify the problem and the computer does everything for you.
This breaks down with the fact that it's really difficult, outside of really constrained spaces, to turn a "what" specification into a high-performance implementation, so any practical language needs to let you give some degree of control in the "how", and as a result, any modern language is somewhere uncomfortably between the 3GL and 4GL in the paradigm, not fitting entirely well in either category.
4GL was really more a marketing slogan than a true generation. The idea was something like "with third generation tools, you have to drive the car, making every turn yourself, with 4th Gen., you say "Go to the Ritz!".
It wasn't true, although they did make some operations easier in tangible ways.
Rust is a wholly different kind of thing -- not easier than, say, Java, but lots more control with better guarantees. It's more a systems programming language. 4GLs were all application-focused.
The modern analogue of 4GLs would be the promise of LLMs letting you write prompts so you don't have to learn a programming language; the promise of the original 4GLs like Pearl (not to be confused with perl) and Objectstar was to let you have non-programmers writing business logic without being COBOL or FORTRAN programmers.
Ironically, the whole reason COBOL has its weird-ass syntax was to let you have non-programmers writing business logic without being assembly or C programmers. We can see how well that worked.
I think about that every time I hear someone saying LLMs will make programmers unemployable. There’s no doubt that the work will change but I think a lot of the premise is based on a fundamental misunderstanding of the problem: business systems are just more complex than people like to think so you’re basically repeating https://xkcd.com/793/ where people higher on the org chart think the problem is just cranking out syntax because they “know” how it should work.
I think we’ve had at least 4 generations of that idea that reducing coding time will be a game-changer: the COBOL/SQL era of English-like languages promising that business people could write or at least read the code directly, 4GLs in the 80s and 90s offering an updated take on that idea, the massive push for outsourcing in the 90s and 2000s cutting the hourly cost down, and now LLMs in the form being pushed by Gartner/McKinsey/etc. In each case there have been some real wins but far less than proponents hoped because the hard problem was deciding what it really needed to do, not hammering out syntax.
There’s also a kind of Jevons paradox at work because even now we still have way more demand than capacity, so any productivity wins are cancelled out. At some point that should plateau but I’m not betting on it being soon.
Soon after Java was released, when the hype around the language was on fire, people used to say that it was going to replace COBOL - due to the "build once run everywhere" motto. Java indeed gained market share in the finance industry, but COBOL is still there.
One reason COBOL systems have been around for so long is because they encoded business rules that need to be understood if you want to try to transfer them to a new system. From the podcast (~16m):
> Like when we're working in unemployment insurance, again during the pandemic, my colleague was talking with the claims processors week over week and we're trying to dissect it and figure out what's going wrong and clear this backlog and one of these guys keeps saying, “Well, I'm not quite sure about that answer. I'm the new guy. I'm the new guy.” And she finally says, “How long have you been here?” And he says, “I've been here 17 years. The guys who really know how this works have been here 25 years or more.”
> So think about. You know, going from doing some simple cool, you know, tech app, you know, easy consumer app to trying to build or fix or improve upon a system that is so complex that it takes 25 years to learn how to process a claim.
> That's sort of, I think, what needs to be on the table as part of this agenda is not just “can the tech be better?” But can we go back and simplify the accumulated like 90 years of policy and process that's making that so hard to make?
Also an observation on how decisions are sometimes made:
> And I think that there's a deep seated culture in government where the policy people are the important people. They do the important stuff and technology, digital is just part of implementation, which is not just the bottom of a software development waterfall. It's the bottom of a big rigid hierarchy in which information and power and insights only flows from the top to the bottom.
> And so it's problematic in part because the people who are doing the tech are really just sort of downstream of everything else and the power and ability and willingness to step up and say “Hey, we probably shouldn't do those 6,700 requirements, we should probably focus on these 200, get that out the door and then, you know, add edge cases as as later.” There's no permission really to say that.
There is not permission to say that because your requirements are often set in a black letter law and you didn't buy a right kind of suite to be present where they were decided for the last 40 years.
> ...add edge cases as as later.” There's no permission really to say that.
I think there would be some value to closing that feedback loop to give legislators the signal "You know, what you're considering is actually pretty fuzzy conceptually... We're discovering while considering how to code it up that you probably don't actually have good, clear definitions for all the terms in this bill." But the biggest thing to remember about government IT is the clientele, which changes the approach from commercial / industry software.
Google can optimize for the common case. Google can cut the edge cases. Google can change APIs on a whim.
Google's users choose to be Google's users and can go elsewhere if they don't like it.
Government citizens don't have that choice. And in general, people don't lose access to their food if Google effs up. Or go without their legally-deserved unemployment pay. Or go to jail because their taxes were mis-calculated.
In the government space, the "edge cases" are human beings, alike in dignity. The rules and policies end up complicated because human beings are complicated. And yeah, it ends up being some messy software. Because you can't just decide to ignore the law when it's inconvenient to plumb the information that the client has a child under the age of 18 who is not a dependent because they're an emancipated minor, but said emancipated minor does have a child of their own, and the client is the primary caregiver for that child while her parent is in prison... from here to there in the dataset.
>Because you can't just decide to ignore the law when it's inconvenient to plumb the information that the client has a child under the age of 18 who is not a dependent because they're an emancipated minor, but said emancipated minor does have a child of their own, and the client is the primary caregiver for that child while her parent is in prison... from here to there in the dataset.
That's all very true, but nobody ever codifies that. When the data doesn't fit the constrains of the form that aims to handle a reasonable generalilized case, you simply get a phone call from a human in the loop. That human has a supervisor and you can also go to a court when they write your name with E instead of É and try to bullshit you about some kind of ASCIEBCDIC nonsense like it's real.
In the end you have one dataset which tells who is a child of who, another telling who has custody rights and a third one making sense of amounts and recipients of childcase subsidies. Maintained by different departments and eventually consistent or maybe not.
My interpretation is a little different. We agree that humans are affected by the edge cases, although I believe that's also true at very large companies like Google or Meta.
I don't think it's about avoiding programming 6700 edge cases, but more so that when you have an excessive number of cases, it's likely an indication that something is being missed. that could be due to a bug in software or due to unclear definitions in the legislation.
in those cases, rather than attempting to program it exactly, it might be better to bring a human into the loop.
and to me, that could be the point of having a tighter feedback loop. because otherwise the developers will just do their best, which will be buggy or incomplete. because they can't not do their job.
I think of scala in this context. I think that scala is basically dead at this point in the way that COBOL was framed in the article. Yes, there are still many businesses/services that have critical components written in scala but current mindshare has cratered for new projects. I only single out scala because I have spent a lot of time with it and have seen it go through the hype cycle (in 2012-14 it seemed like I was constantly seeing doing $X in scala pieces on HN and I almost never see it referenced here anymore). It's probably a natural and inevitable phenomenon (and a bit of a shame because scala did get some things right that other mainstream languages still have not).
I know a couple of engineering teams at Apple that are working on new projects in Scala, while also maintaining some legacy systems. Some of these projects are quite critical to the company’s ecosystem, e.g. test systems. I’ve spoken with several engineers who helped create these systems years ago; they’re all now in senior management positions. Some still stand by the technology choices made back then, while others are more open when given a chance to reflect. The general consensus is that if Kotlin had been available at the time, or if Swift had been a viable option for back-end services, they definitely wouldn’t have chosen Scala for those projects.
Scala can never be dead like COBOL because it has never been alive like Google. I love it too, but Scala has always been fringe. COBOL was everywhere.
What about spark? Given the incredible adoption of spark across the industry I don't see scala going away anytime soon.
I assume it became less popular when Java became more bearable.
And kotlin came around with great IDE support, and with good features without the complexity of scals
Kotlin made Java bearable.
Does Twitter still have software in Scala?
You know, one of these days I really need to sit down and play with some of these "legacy" languages, like Fortran or COBOL or Ada or APL; languages that have certainly fallen out of popularity but are still used in some critical places.
It does make me wonder about millions and millions of lines of Java out there; Java has more or less eaten the enterprise space (for better or worse), but is there any reason to think that in 30-40 years the only people writing Java will be retirees maintaining old banking systems?
Cobol is still there not because of cobol itself, but because of vendor and platform lock-in. And I guess having monolithic codebase/platform.
it’s not even esoteric and difficult, just a lot of it without much structure visible to you.
This is what people miss about COBOL. It's not like people are compiling COBOL and running it on Linux on an x86 box. They are running it on legacy operating systems (and hardware) which provide a different set of underlying services. It's a whole different planet.
Negativo friendo.
The mainframe is turning into a middleware layer running on Enterprise Linux. We've containerized the mainframe at this point, and I mean that directly - eg. Running jcl, multiple CICS regions, all in COBOL that originated on z/OS is now running in k8s on amd64.
I hope you're right, but many comments here on HN suggest their experience with mainframes is very different. z/OS and its predecessors provided so many services completely transparently to the application that a mainframe to modernity migration is doomed to fail unless it can completely emulate (or design around) the capabilities provided by the OS and other subsystems.
Even ignoring the needs of the super high end customers like banks (eg, cpus in lockstep for redundancy), being able to write your app and just k ow that inter node message passing is guaranteed, storage io is guaranteed, failover and transaction processing is guaranteed, just raises the bar for any contender.
K8s is wonderful. Can it make all the above happen? Well, yes, given effort. If I'm the CTO of an airline, do I want to shell out money to make it happen, risk it blowing up in my face, or should I just pay IBM to keep the lights on, kick the can down the road, and divert precious capital to something with a more obvious ROI? I think their "no disasters on my watch/self preservation" instinct kicks in, and I can't really blame them.
Hn thread:
https://news.ycombinator.com/item?id=36846195
There is a major drawback to this approach -- you need to have somebody who knows what they are doing. Total deal breaker in most of the places that have this problem in the first place.
"you need to have somebody who knows what they are doing"
That applies everywhere.
Your parent comment has managed to stuff a mainframe in a container and suddenly, hardware is no longer an issue. COBOL is well documented too so all good and so too will be the OS they are emulating. I used to look after a System 36 and I remember a creaking book shelf.
The code base may have some issues but it will be well battle tested due to age. Its COBOL so it is legible and understandable, even by the cool kids.
If you lack the skills to engage with something then, yes, there will be snags. If you are prepared to read specs, manuals and have some reasonable programing aptitude and so on then you will be golden. No need for geniuses, just conscientious hard workers.
It's not rocket science.
Yup, but the COBOL application doesn't know you've done that.
A different kind of cloud you can say.
ha yes. There is actually a pretty cool product that is made by a division of Rocket Software named "AMC", it takes a COBOL app running on an IBM system and deploys it to a whole set of services on AWS. There are some smart dudes at that shop.
Doesn't surprise me at all, somebody out there should be smart enough to make good money on that and not be very loud about it either.
Ada is an order of magnitude more modern and sophisticated than your other examples.
I expect Ada will capture 0.05% of the market for the next 100 years.
Fair, I guess the list was “languages that I know were popular at one point but I don’t know anyone really using now”.
Ada definitely does seem pretty cool from the little bit I have read about it. I’m not sure why it’s fallen by the wayside in favor of C and its derivatives.
Ada was mandated by the DoD for a bit. My understanding is that, in practice, this involved making a half-hearted effort in Ada, failing and then applying for a variance to not use Ada.
Often, I'm sure, but there are large code bases in Ada still. It's a shame, it looks like a really great language I would love. But it's a chicken and egg problem. If only Mozilla had decided on Ada instead of Rust! :-)
I actually met a programmer who worked on military jets. According to her, Ada is only used anymore for the older jets that were already programmed in it, and she worked in C++.
Ada is pretty cool, but not sure if any more modern than APL. Both are actively maintained and useful in different areas.
Tryapl.org exists if want to play with APL - John Scholes' Game of Life and other excellent videos (https://www.youtube.com/watch?v=a9xAKttWgP4) might spark your interest
Other newer array languages exist too - https://aplwiki.com/wiki/Running_APL if want to explore the current space.
I program an Android app for a Fortune 100 company. Last commit where someone edited a Java file was last week.
Most of the new code from the past few years has been in Kotlin though.
This. Nobody wants to have the COBOL problem again, so the developer hiring money follows the programming language popularity market (with a certain regulatory approved laf ofc)
“laf” or “lag”?
>but is there any reason to think that in 30-40 years the only people writing Java will be retirees maintaining old banking systems?
It feels like we're getting into that space already.
Nah not really. People just started replacing COBOL with java and employers are wise enough to hire people who are 30-40 years minimum from retirement.
It can also be upgraded in smaller chunks and finding enough developers for the tool is an important metric corporate is looking at.
If anything, banks are actively optimizing for developer experience to make sure 60% of new hires don’t run away in the first year. If anything, banks are better at navigating those kind of structural risks, they were just slow on undertaking such risks exist.
If you have an episode of existential anxiety because of dat AI eating mijn job, getting a union job in a bank is a way to hedge this particular risk.
> ...employers are wise enough to hire people who are 30-40 years minimum from retirement.
Um oh yeah, the reason we're hiring 20-year-olds is because we want to ensure we have lifelong support for the new system we're writing. Not because they're cheaper, they're still idealistic and naive, they'll work long hours for foosball tables and stacks, or anything like that...
In a place where you can imagine having COBOL, working long hours is frown upon and being idealistic beyond personal integrity isn't a good quality either. Not saying such places aren't cheap, as of course they are. Being cheap is their exact point.
I think Android makes a difference here. Sure, a lot of people are on Kotlin, but a lot aren't.
Fortran is not a legacy language.
IBM offers a free COBOL plugin for VSCode and a nice tutorial with it.
I started programming in COBOL (circa 1990) and took the tutorial just for fun earlier this year.
Article starts mentioning 4GL's - a term I have not heard in a long, long time.
COBOL's promise was that it was human-like text, so we wouldn't need programmers anymore. A lot like "low code" platforms, and now LLM generated code.
The problem is that the average person doesn't know how to explain & solve a problem in sufficient detail to get a working solution. When you get down to breaking down that problem... you become a programmer.
The main lesson of COBOL is that it isn't the computer interface/language that necessitates a programmer.
> COBOL's promise was that it was human-like text, so we wouldn't need programmers anymore. A lot like "low code" platforms, and now LLM generated code.
The more things change, the more they are the same.
> we wouldn't need programmers anymore
This blows my mind, since it seems like a fairly low level/terse language compared to more modern domain specific languages.
But in some sense they were dead right... since (I assume) that what "programming" meant at the time was being able to write raw machine code by hand on paper, and have it work - something few people can or need to do nowadays
> This blows my mind, since it seems like a fairly low level/terse language compared to more modern domain specific languages.
I have heard others and myself describe COBOL in many ways, most involving creative expletive phraseology which would make a sailor blush, but "low level/terse language" is a new one to me.
> But in some sense they were dead right... since (I assume) that what "programming" meant at the time was being able to write raw machine code by hand on paper ...
LISP and Fortran predate COBOL IIRC.
Vision 4GL. Like VB but cross platform and with a horribly unstable IDE which would corrupt the source code. (Which was in some kind of binary format not amenable to source control.)
Do open source COBOL programs exist? Just wondering since I see it mentioned occasionally here.
For what it's worth, I'm still actively looking for a COBOL speaker for the 2025 Carolina Code Conference. Been wanting to get a COBOL talk for a while, especially with GnuCOBOL's recent update.
https://gnucobol.sourceforge.io/
https://carolina.codes
"I don't know what the language of the year 2000 will look like, but I know it will be called Fortran." —Tony Hoare
COBOL is alive in that it keeps changing from era to era, to the point modern COBOL looks rather little like the 1950s COBOL everyone instinctively thinks about when they heard the term. It's as if we were still programming in Algol because Java had been called Algol-94 or something.
Nobody writes
any more.> print food if tasty?
Ruby is nice.
Maybe I'm in a minority, but I genuinely dislike conditions placed afterwards.
They feel great to type out when you're in the flow, but coming back and reading them grates on my nerves. Seeing the condition first means I load a logical branch into my mental context. Seeing the condition after means I have to rewrite the context of what I just read to become part of a logical branch, and now the flow of reading is broken.
I mean, if you squint your eyes a bit, that could be SQL! So even if it's not COBOL, there's people out there writing in a vaguely english business programming language.
So you spotted that? I have no proof or links to share, but I've always thought SQL was inspired by, or at least made to not look out of place next to COBOL. I recall COBOL coding card layout interpreted a flag on punch cards at the char column where top-level picture clauses needed to start specifically for designating a line as SQL for static embedded SQL preprocessing.
I think it’s more that computers at the time didn’t all have lowercase characters. Consider that even C and C++ supported trigraph/digraph compatibility chars until something like last year (and IBM still complained…):
C is much older than Unicode, so it's not that surprising that some systems are still using https://en.wikipedia.org/wiki/ISO/IEC_646 and replacing some reserved punctuation (e.g., curly braces) with their country's accented letters.
The nice thing about a vaguely English like language is that your average LLM is going to do a better job of making sense of it. Because it can leverage its learnings from the entire training set, not just the code-specific portion of it.
Not for generating it, because the more it looks like prose the more the LLM's output will be influenced by all the prose it's ingested.
I've used o365 copilot to analyze a COBOL app I had source code to, and it was great at explaining how the code worked. Made writing an interface to it a breeze with some sample code and I swear I am not a COBOL person, I'm just the Linux guy trying to help a buddy out...
It also does a reasonable job of generating working COBOL. I had to fix up just a few errors in the data definitions as the llm generated badly sized data members, but it was pretty smooth. Much smoother than my experiences with llm's and Python. What a crap shoot Python is with llm's...
And SQL kinda dates from the same era, I wonder if this type of language was in vogue 50 years ago?
seriously sometimes writing SQL feels more like composing a google query than programming.
A great thing about being a programmer is getting to complain about the crappy requirements you have to work with. SQL, on the other hand, is not a program - it’s a precise specification of the result you want, in a format that lets the database engine write the “program” for you. Thus, writing SQL helps you appreciate the struggle to achieve good requirements, and there is a chance you will develop empathy for those cursed to write them.
More accurate might be "I don't know what the language of 2000 will be called, but I know it will look like Fortran."
This was almost true in 2000. It is not true now. Things change. Slowly.
But are these legacy systems from the 70s, 80s, 90s using modern cobol?
Depends what you mean; but not necessarily.
I am managing an ERP system implemented / went live in 2016. It's working on modern P10 hardware, which was released in 2021. The ERP system is continually updated by the vendor and customized by the client.
Even for COBOL running on an actual mainframe, which I think most HNers would think of 1970s dinosaur, most of the actual machines in production would be pretty new. IBM z16 was launched in 2022.
So they are "legacy systems" in the sense they're not written on a javascript framework which was launched last week, running on lambda instances in AWS :). But they are not "OLD" systems, as such.
Almost certainly yes. The "legacy systems" are likely running on versions of the mainframe with long-term support contracts, whose vendors are committed to providing newer compilers with support for newer versions of the specification as necessary.
When you hear about people being paid $X vs 10x$X to fix some cobol; is there a correlation between the age of the cobol system?
Probably not; just a matter of how desperate they are.
> "I don't know what the language of the year 2000 will look like, but I know it will be called Fortran." —Tony Hoare
Kemeny and Kurtz described Fortran as "old-fashioned" in 1968! <https://dtss.dartmouth.edu/sciencearticle/index.html>
As always, these discussions will depend on your definition of "dead" and "alive".
If we can call a technology dead once no new business is built on it, then I think we can safely call COBOL dead (and the IBM 390x aka Z/OS platform along with it, for which "COBOL" is usually a proxy).
But if we say that anything still being used in production is not dead, then of course COBOL is alive and significantly more alive than many other things which are younger than it.
But this shouldn't really be taken as a positive point for COBOL or the mainframe ecosystem. It's simply a fact of life that organizations tend to stick with the first thing that works, and for the types of entities involved in the first wave of digitalization (e.g. governments, banks, airlines) that was usually an IBM mainframe along with the software that runs on it.
> we can call a technology dead once no new business is built on it
You don’t suppose any bank - or other large financial institution - might have standardised on Cobol for their core business flows/processes? In which case a new business-unit or “internal startup” team (e.g. a new category of insurance product) might very-well have some part written in Cobol so it integrates with the rest of the bank - or at very-least might be built-on-top of the org’s existing Cobol-running infrastructure (i.e. Not written in Cobol, but still runs on Z/OS because there’s no budget for buying new commodity x86 racks and the people to manage and run them).
Sure, I know for a fact that what you're describing exists. That's not really what I mean by new business being built on it. That's a case of a very large and old business already being so locked into the mainframe ecosystem for their core systems that anything new they try to do ends up needing some kind of integration system with the legacy system.
What I mean is that nobody starts a business today and says "Ok, we need an IBM mainframe running DB2 and we'll have a bunch of COBOL, ReXX, and PL/I programs for handling our business logic".
A touching article! I have enjoyed similar times with my grandpa. On the topic of Cobol, I simply don't understand why people hate it so much. It has a shallow learning curve like Python, is self-documenting enough that one doesn't need to write a bunch of text, and is available on every conceivable architecture, with great performance. I personally wrote a payroll for an entire factory on a B1800 with 128K of memory and a 10MB hard disk! So what's to complain? In my mind, Java is deader than Cobol!
Its the amount of boiler plate that people hate.
I think there’s something to that but there’s also a lot of selectivity there. Many of the same people who complained about COBOL because it was verbose adopted things like enterprise Java, so there’s more than a suggestion that this might be a less than completely objective assessment.
The bigger problem: COBOL was an open standard but none of the implementations were open source for ages (I haven’t looked at GNU COBOL in years, but I think this is no longer the case) so nobody was building new things or experience when they had to pay to get started.
Note: I'm getting some hate from others who think I would pick or prefer COBOL over a modern language. I wouldn't. I was making an outside-the-box "devil's advocate" objective observation. I just wanted to preface that here. Okay, the rest of my original comment remains below:
The irony is that we already had a memory safe and stable language in Cobol that was easier to read and understand than Rust. But, no one wants to use it so it is "dead" but it runs everything that made the modern age possible.
RUST:
println!("Enter number: ");
let mut input_string = String::new();
io::stdin().read_line(&mut input_string).unwrap();
let number: i32 = input_string.trim().parse().expect("Please enter a valid number.");
let result = if number % 2 == 0 {
} else { };println!("The number: {}", result);
COBOL:
display 'Enter number: '
accept number
if function mod(number,2) = 0
else end-ifdisplay 'The number: ',result
This is a weird take. Sure, plenty of cool/nice things from old languages (e.g. variable-sized stack frames in Ada) get lost, and some then get rediscovered by future languages, potentially wasting effort. And I don't know COBOL, so maybe you're actually making a good point.
But I find that hard to believe. Does COBOL really solve all the same problems Rust is intended to solve? Is it as performant? Can it interface with native code from other languages in the same way? Does it have a usable and sane package manager built on top of a module system that facilitates composability and backward compatibility? Does it have a way to describe the shape of data and errors as ergonomically as Rust's algebraic data types?
Genuinely curious: as I said, I don't know COBOL. I'd find it extremely surprising if the answers to all these questions are "yes," though. Just as there are reasons COBOL is still used, there are also (good) reasons new languages have been created.
A lot to unpack in this question.
Do they solve all the same problems? No, for example COBOL lacks a modern concept of concurrency within a single program. COBOL's concurrency features are based on task-level parallelism, which involves dividing a program into multiple tasks that can be executed concurrently.
Is it performant? Yes. COBOL is highly efficient particularly in handling large datasets and complex business logic and its compilers are optimized for reliability and speed.
Can it interface with native code? Yes.
Does it have a package manager? No.
Does it describe shape of data? No. Data structures in COBOL are defined using fixed-length records.
Note: I'm not a COBOL expert. I did learn it in college, though.
Imagine having a shell script being called from a cron job that writes data in a bunch of tab separated memory mapped files (memory mapping happens when you configure the thing), but you have more files than memory. And all the shell scripts call and include each other and have global variables too.
And that underpins most of the critical infrastructure in your country.
It's a bit odd to say these programs are comparable when the Cobol version isn't handling errors whereas the Rust program is (by panicking, but that's better than the silently wrong behavior of the Cobol one). Here's a runnable version of the above Cobol program (adding the necessary boilerplate); note that it prints "even" for an input of `abc` and "odd" for an input of `12`:
It's peculiar to call out Rust's syntax specifically when, like most other languages these days, is mostly C-like (though with a sprinkling of OCaml). And syntax aside, Rust and Cobol have wildly different goals, so "just use Cobol" doesn't suffice to obviate Rust's purpose for existing.Good catch! My cobol is rust-y. :D
I guess my post is getting misread as "just use cobol" when it was more of a XKCD-like reflection; e.g. why did we all do that / keep doing that. We done did Cobol, and Rust. And, one is "dead" but not really and now here we are.
https://xkcd.com/927/
Sorry, https://www.ibm.com/docs/en/cobol-zos/6.2?topic=statement-ex... seems to be demonstrating a language that is not memory-safe (maybe it used to be, but how?)
The compiler would have rejected that, if I remember correctly. I'm not in the field of cobol myself, I learned it briefly in college ages ago.
Shell script is memory safe too, but you don't write anything longer than 100 lines in it for a reason.
When you bank, COBOL (40% of online banks). When you use the ATM, COBOL (95% of ATM transactions). When you travel, COBOL (96% of airline ticket bookings). Healthcare, COBOL. Social Security, COBOL. Point of Sale, COBOL. IRS, COBOL. Pension funds? COBOL. Hotel bookings? COBOL. Payroll programs? COBOL.
It is estimated that there is 800 billion lines of COBOL code in production systems in daily use. That is a bit more than 100 lines.
This was why Y2K genuinely scared everyone and was a very real problem. The only reason we can look back at it and laugh now is that an army of engineers sat down and rewrote it all in the nick of time.
I'm a big enjoyer of arcain arts, but I happen to work in a place that actually has it and no -- nobody likes COBOL and it's not cool in any sense.
Well, there is a good reason no one likes it. It isn't cool, I completely agree. Readable, simple, safe, performant and still relevant though? Ya.
>Readable, simple, safe, performant and still relevant though?
It's performant, you can't take away that.
Legacy code yeah, nobody's hitting File > New Project in COBOL
It's just that nobody understands how the systems work and they're ossified. Those systems are going to be emulated until our grandchildren take over because nobody can understand them well enough to craft a replacement. Juuuust up until an LLM rewrites them for us.
[edit] I mean those airlines systems are so old that they don't support special characters on names, passenger names are two fixed-length fields (first name, last name) and title and middle name just gets appended together.
So you get LASTNAME/FIRSTNAMEMIDDLENAMENTITLE on your bookings. And each of those fields is truncated lol.
and of course flight numbers are fixed at 4 digits, so we're running out of those.
Not exactly a great ad.
"Legacy code" is also known as "the important code that makes the business work"
If these new fangled languages are so great, one day they can be legacy code too. :P
That's not what makes something legacy. Legacy is something highly not advisable to change because it's both makes the business work and can't be easily changed because of complexity, loss of context, high blast radius or whatever. It's just there and you have to deal with it. If it wasn't complex, opaque and scary to touch it would not have been just another piece of something to be replaced and updated like the copyright date in the footer.
Oof, I've got good news and bad news for you.... they still are creating new code in it.
Yeah, there are fewer engineers in COBOL which is why it pays BIG bucks now. They desperately need someone to maintain that massive infrastructure that has been built up over 75 years that cannot be replaced easily or quickly.
Besides - standard COBOL is only "memory-safe" by way of not supporting dynamic memory allocation. Like, at all. Even strings are stored in fixed-length arrays.
"A ship in harbor is safe, but that is not what ships are built for."
Bizarre comment. No developer who should be allowed anywhere near a computer would ever consider choosing COBOL where Rust is appropriate or vice versa.
Well, I said it was ironic that we went out of our way to make a newer more complicated to read language that was memory safe when we already had a language that was simpler and readable that was safe.
I didn't say I wanted to code in it, though. I'd prefer in no particular order Kotlin, Python, Go, C++, Rust, Perl, C#, Java, Zig, etc. Anything really over COBOL myself. I'm part of the problem.
But, if I was hard up for money and wasn't getting nibbles for jobs? I could see getting into COBOL because there is a lot of money in it and always work available.
My statement stands though, we need to do better when designing the syntax of our languages. Cobol is disliked, yet simple and readable. What does that say about our new languages. How hated are our "new" language remnants going to be when few of us are longer around to maintain them 50 - 75 years from now? And, how easy are they going to be to pick up?
Addendum: I guess it won't matter if the singularity comes and just writes it all for us, of course. Then it will all just be machine code and we won't need these "only human" translation layers any longer.
I don't think the use cases for Cobol (bank software) typically overlap with those for Rust (operating systems...etc).
It's like saying no gardener should be allowed near a garden that would choose a shovel over a pair of shears. Both have a place.
Agreed. It's easy to have memory safety when you don't even support heap allocation. Now if OP had said "Java" or "C#" instead of "COBOL", they would've had a solid point. But the way Rust ensures memory safety without mandating GC while still allowing for complex allocation patterns can be said to be practically unfeasible for any of the usual "legacy" languages, with the notable exception of Ada.
Started my career doing Y2K stuff in 1998 and I still touch COBOL here and there today. I have a 10,000 line CICS program that runs every 30 seconds that I wrote in 2010. It has never failed since.
That's what I liked about developing Oracle stored procedures activated by cron jobs. Ran for 5 years, no maintenance needed.
That seems like a low barrier of expectations. I can think of several DB's that would run exactly like that.
I don't understand these "never failed" comments. Without further context, it's meaningless. If I write a python script and never change anything in its environtment or inputs, it won't fail either. That's not specific to cobol.
COBOL changes very slowly, once in a decade or two. Python does not offer support of a release for more than 3 years and a half [1].
[1] https://en.wikipedia.org/wiki/History_of_Python
I could believe there are legacy installations happily humming away on Python 2.7 without issue.
Several years ago I briefly worked at a major telecommunications provider with services across the southern United States that ran Python 2.4 on their production provisioning servers. Worked just fine.
But a compute instance or bare metal computer that never needs a new release wont have to deal with that in python either
Its only new builds on someone else’s computer that have this modern issue
I imagine the backwards compatibility story of COBOL is a little better than Python's
I understand the context to be that COBOL, as a DSL for batch processing, declares its .data and .bss segments, or the equivalents on host systems, statically in the DATA DIVISION and usually doesn't dynamically allocate memory. This, coupled with CPU, memory, and I/O bandwidth reservation from a job scheduler on an exclusive hot-swappable partition on a host (z/OS aka MVS) plus USVs, redundant disks/disk ports, and networks makes "never fail" much more a consequence and primary objective of mainframe architectures where COBOL workloads are usually run.
If you're actually patching your python installs, that is by no means certain.
I don’t think those mainframes running COBOL are getting patched either.
They absolutely are. Modern COBOL (even 25 year old COBOL) isn't running on ancient System360/370/390s or something, it's running on modern z/OS mainframes.
They are patched up regularly. The COBOL code itself maybe not, but the runtimes?
Technologies die very slowly once things of economic value depend on them. COBOL probably isn't used from new projects very often, but the economics of ditching it aren't very good either. It already works. Rewriting things that work is a great way to create new problems at great expense, so institutions are hesitant.
Just this week a colleague asked if someone knew Cobol. Apparently another team had a Cobol-related issue.
So despite its long death, it still seems to be kicking about. I doubt we'll ever get rid of it.
It's interesting reading articles from previous generations how they make it sound like people seem to remember what everyone in the tech industry said as if everyone mattered. I guess there weren't many people around in the industry back then.
Nowadays, even if someone is right about something and most people are doing it wrong, nobody will care to even discuss it unless the person making the statement is one of maybe 3 top influencers in that field.
I worked for a company in the late 1980s that started developing with a 4GL product (Dataflex) instead of COBOL. The article is right that COBOL has outlasted most (all?) of those 4GL solutions.
Looking back, COBOL would have been a better technical choice back then. Dataflex's metadata-based dynamic UI and report generation saved some simple, repetitive work, but much more effort was wasted working around its limitations.
COBOL is dead, long live COBOL.
For any cobol devs here, we at https://cobolcopilot.com would love to hear from you
You need to sell on-prem to those people. No way a single byte of that sweet sweet poison is going to ever leave the corporate network boundary.
almost all major financial institutions, utilities, gov't agencies, etc still rely heavily on COBOL today. If it ain't (extremely) broken, don't fix it?
COBOL developers are literally dying out which has made for a competitive market for remaining talent. I've heard of some large consultants charging over $500/hr to their clients for a COBOL developer!
I feel like every time COBOL is mentioned we get these stories about crazy high comp for COBOL developers, but anecdotally my aunt worked on COBOL projects in the mid 2010s and was paid a much more modest 45 $/hr. Good money for small town middle America where she lives, but nowhere close to what a decent JS dev can get.
Similar experience with a friend of mine. I feel like these high salaries only apply to people who habe worked at one of these companies for a looong time.
High salaries are relative. $90k is a high salary for most people in the world, even for tech workers outside of Silicon Valley.
In COBOL implementations, it's generally not just knowledge of the language that makes you valuable, it's knowledge of the implementation at that particular organization. I'm not a COBOL dev myself, but I work with them, and part of the challenge is that everything is so uber-customized, tightly coupled, and there's 40+ years of undocumented business logic buried in the code.
It's like the old joke about the engineer being asked for an itemized bill: "Chalk mark: $1. Knowing where to put it: $4,999."
I work for a major utility and they used to run everything on mainframe and cobol but that went away long before I started programming. My coworker is nearing retirement, around 30 years here, and he started on cobol and worked on transitioning off. He has some really fun stories but my point being, the tales of cobol prevalence are very exaggerated. Maybe some parts of finance are still using it, not my area.
I think the moat that COBOL developers have is not just their knowledge of the language, but knowledge of the mainframe programming and operating environment. Its just so alien to developers familiar with Windows/Linux, and there is really no way to get experience with the environment that I know of, other than to be employed doing it.
But yeah that stuff is never going away as far as I can tell. Its just too risky to rewrite those core systems and many a boondoggle has tried and failed.
Migrations are still a thing, with various approaches and success rates.
About a decade ago I looked into moving some COBOL components off-mainframe (either as COBOL-on-Linux or a rewrite into Java, which itself is really COBOL Mk II at this point), and your point about the operating environment is one of the key elements, but not all of it; there's also the fact that the first big shift to automation, via mainframe assembler and COBOL, is when companies sacked a lot of the folks who knew how and why the pre-automation processes worked - that knowledge exists in the mainframe code and the heads of the people who work(ed) on it, and nowhere else. A rewrite or a replatform is very, very hard and risky as a result; the system is now defined by how the mainframe runs the processes, to a very large degree.
The third is that COBOL is only the tip of the iceberg. As soon as I spent time learning about the code I was being asked to look at, you get into decades of evolving programming practises. Modern COBOL is multithreaded, probably uses DB2 and relational datamodels. COBOL from thirty years ago is probably single-threaded, only runs right on high-clocked single-execution models, cuts down to hand-written s390 assembler regularly, and uses VSAM files with non-relational data. Older code still will be sharing data simply by banging it into memory regions for other code to read out of, because that's how you got performance back in the day.
Trying to identify how you'd pull a function out of that and move it off is somewhere between extremely difficult and impossible. It's usually so complicated and expensive it's easier to try and hire people who want to apprentice as mainframe programmers and keep the current codebase running.
> A rewrite or a replatform is very, very hard and risky as a result; the system is now defined by how the mainframe runs the processes, to a very large degree.
And that's why so many neo-banks/fintechs are eating the lunch of the established banks left and right, same for insurance. The "old guard" is unwilling to pay the costs of not just upgrading off of mainframes (aka the rewrite work itself)... but of changing their processes. That is where the real cost is at:
When you have 213.000 employees like BoA has and everyone needs to have at least 10 hours of training and 2 weeks until they're familiar with the new system enough to be fully productive, that's like 2 million man-hours just for training and 16 million hours in lost productivity, so assuming $50/h average salary it's around 900 million dollars in cost. Unfortunately for the dinosaurs, the demands of both the customers and (at least in Europe) regulatory agencies especially for real-time financial transfers just push the old mainframe stuff to limits, while at the same time banks don't want to cede more and more of that cake to Paypal and friends that charge quite the sum for (effectively) lending money to banks.
In contrast, all the newcomers start with greenfield IT, most likely some sort of more-or-less standard SAP. That one actually supports running unit and integration tests automatically, drastically reducing the chance of fuck-ups that might draw in unwanted regulatory attention.
BOA doesn't train the vast, vast majority of its workforce on mainframe systems these days. No one working in a branch or call center is looking at green screens anymore. The mainframe systems are simply used as back-ends connected through web services (yes, even in CICS!) or MQ Series and the like to web GUIs.
Source: worked there for many years, and built some of those integration systems.
Can't we just apply a bunch of correctness preserving translations towards a modern PL, perhaps aided by an LLM to keep the source as human readable as possible, while (I'm stressing this) preserving correctness?
IBM offers just such a service under the WatsonX branding, it's an LLM to convert COBOL to Java: https://www.ibm.com/products/watsonx-code-assistant-z
I work at a company with a large COBOL codebase and this has been mentioned in a few presentations about our modernization efforts.
But is the conversion maintainable by a human? I’ve seen Fortran to C translators that end up encoding state transition machines that are impossible to read.
You should take a look at my company. Heirloom Computing. Heirloom.cc We have migrated many mainframe application and millions of lines of cobol and pl1 into Java and deployed it into production on prem and into the cloud.
How did that go? My employer is going to try snd evaluate watsonx product. Have you had any luck converting large/complex COBOL modules ?
You can’t, unless you transform cobol to cobol and run the emulator on aws. It will still manage to fail you in some way
That seems like a myth to me. I actually looked up COBOL salaries and they were a bit higher (like 20%) but definitely not enough to make them tempting.
There is typically a big difference between a consultant's hourly rate and a full time salary hourly rate.
It is very much broken and said institutions don’t like it
COBOL jobs are not particularly well paid in my country.
In any case, they would have to pay well by a large margin to justify working on dead boring legacy systems, too.
(Programming) languages take very long to "die". Most often you will get a long drawn out tail, and often parts of a language gets absorbed into other languages. Only the sages and etymologists will know where they have come from.
Old man reminiscence following, skip if you are not bored:
I worked with SNOBOL and I thought it will be a long term programming language. I also want to think that I had some tiny, minuscule hand in dev of RIPscrip pre-Telegraphix, alas it went as the dodo bird.
I think I have forgotten more programming languages than I can count on my hands. Yet, I see them in some part every day in newer languages, "discovered" by some expert. "What has been will be again, what has been done will be done again; there is nothing new under the sun."
One language has come to my aid for the last 30-ish years Perl has came to my aid many times.
(I tell you a secret - in the deep deep bowels of a a very, very large, jungle named company, servers still have tiny Perl scripts running some core functions. I discovered this, when there was a problem that I had to deep dive into. I a recommendation to change to a hard-coded variable. The answer was "it will take two weeks". Why? Because no one knew what it will do or could read Perl. It was a 30 second job, including sdlc. Think xkcd Dependency https://xkcd.com/2347/ )
huh so are any languages actually dead? ChatGPT mentions FORTRAN, ALGOL, or Pascal... which I don't think are dead at all.
Ada I've never heard of, so maybe that one's dead?
If they're able to write WebAssembly compilers for all these languages, then they'll probably live forever!
The only reason punchcards are "dead" is bc the machines are gone or mostly unavailable...
Ada is still updated, last released in 2023. Given its original audience is the Department of Defense, it seems to me very likely it is far from dead.
As long as there are tactical nukes that depend on COBOL, COBOL ain't dead.
We might all die, but COBOL will sit happy in its steel reinforce nuclear bunker
Still doesn't beat Assembly, which will continue running on Voyager 1 even after the inevitable demise of our planet. Would survive the end of our solar system too.
Great story. There's something wicked personal in it, and it's very good. I reckon that this bloke's grandfather was an interesting bloke - cobol or no.
I know someone my age (mid-late 30s) who is a COBOL programmer for a bank.
He's been that for ~5 years.
I don't think it's going away any time soon.
Frankly, in all these stories about COBOL programs being modified for Y2K and whatever... isn't COBOL a compiled language? What's really amazing is that all these legacy systems have buildable source code and the toolchain to build them with i.e. that that stuff hasn't suffered "bit rot" or other neglect.
Key components of the U.S. Internal Revenue Service tax processing code (e.g., the "Individual Master File" or IMF) are written in COBOL and IBM Assembly Language.
There is an ongoing effort to refactor as Java. This will ultimately take years and cost $100s of millions of dollars. There is still a small but shrinking team of graybeards who can actually maintain the code, which has to be reprogrammed every year to accommodate changes to tax code.
See, e.g., IRS IT Strategic Plan documents, publicly available.
Huh, so it mentions 4GLs… what generation would we consider rust/kotlin/swift then?
The idea of programming language generations were based on paradigms of programming that never really caught on. The idea, roughly, is that 3GL are those languages where you specify how something is to be done, 4GL is where you specify what is to be done instead, and 5GL is you specify the problem and the computer does everything for you.
This breaks down with the fact that it's really difficult, outside of really constrained spaces, to turn a "what" specification into a high-performance implementation, so any practical language needs to let you give some degree of control in the "how", and as a result, any modern language is somewhere uncomfortably between the 3GL and 4GL in the paradigm, not fitting entirely well in either category.
third generation: https://en.wikipedia.org/wiki/Third-generation_programming_l...
They haven’t been around long enough to even be considered in the running.
4GL was really more a marketing slogan than a true generation. The idea was something like "with third generation tools, you have to drive the car, making every turn yourself, with 4th Gen., you say "Go to the Ritz!".
It wasn't true, although they did make some operations easier in tangible ways.
Rust is a wholly different kind of thing -- not easier than, say, Java, but lots more control with better guarantees. It's more a systems programming language. 4GLs were all application-focused.
The modern analogue of 4GLs would be the promise of LLMs letting you write prompts so you don't have to learn a programming language; the promise of the original 4GLs like Pearl (not to be confused with perl) and Objectstar was to let you have non-programmers writing business logic without being COBOL or FORTRAN programmers.
Ironically, the whole reason COBOL has its weird-ass syntax was to let you have non-programmers writing business logic without being assembly or C programmers. We can see how well that worked.
I think about that every time I hear someone saying LLMs will make programmers unemployable. There’s no doubt that the work will change but I think a lot of the premise is based on a fundamental misunderstanding of the problem: business systems are just more complex than people like to think so you’re basically repeating https://xkcd.com/793/ where people higher on the org chart think the problem is just cranking out syntax because they “know” how it should work.
I think we’ve had at least 4 generations of that idea that reducing coding time will be a game-changer: the COBOL/SQL era of English-like languages promising that business people could write or at least read the code directly, 4GLs in the 80s and 90s offering an updated take on that idea, the massive push for outsourcing in the 90s and 2000s cutting the hourly cost down, and now LLMs in the form being pushed by Gartner/McKinsey/etc. In each case there have been some real wins but far less than proponents hoped because the hard problem was deciding what it really needed to do, not hammering out syntax.
There’s also a kind of Jevons paradox at work because even now we still have way more demand than capacity, so any productivity wins are cancelled out. At some point that should plateau but I’m not betting on it being soon.
Soon after Java was released, when the hype around the language was on fire, people used to say that it was going to replace COBOL - due to the "build once run everywhere" motto. Java indeed gained market share in the finance industry, but COBOL is still there.
Is PERL dead yet?
PERL is undead.
No
Bloomberg's Odd Lots podcast had an episode last year, "This Is What Happens When Governments Build Software":
* https://www.youtube.com/watch?v=nMtOv6DFn1U
One reason COBOL systems have been around for so long is because they encoded business rules that need to be understood if you want to try to transfer them to a new system. From the podcast (~16m):
> Like when we're working in unemployment insurance, again during the pandemic, my colleague was talking with the claims processors week over week and we're trying to dissect it and figure out what's going wrong and clear this backlog and one of these guys keeps saying, “Well, I'm not quite sure about that answer. I'm the new guy. I'm the new guy.” And she finally says, “How long have you been here?” And he says, “I've been here 17 years. The guys who really know how this works have been here 25 years or more.”
> So think about. You know, going from doing some simple cool, you know, tech app, you know, easy consumer app to trying to build or fix or improve upon a system that is so complex that it takes 25 years to learn how to process a claim.
> That's sort of, I think, what needs to be on the table as part of this agenda is not just “can the tech be better?” But can we go back and simplify the accumulated like 90 years of policy and process that's making that so hard to make?
Also an observation on how decisions are sometimes made:
> And I think that there's a deep seated culture in government where the policy people are the important people. They do the important stuff and technology, digital is just part of implementation, which is not just the bottom of a software development waterfall. It's the bottom of a big rigid hierarchy in which information and power and insights only flows from the top to the bottom.
> And so it's problematic in part because the people who are doing the tech are really just sort of downstream of everything else and the power and ability and willingness to step up and say “Hey, we probably shouldn't do those 6,700 requirements, we should probably focus on these 200, get that out the door and then, you know, add edge cases as as later.” There's no permission really to say that.
> There's no permission really to say that.
There is not permission to say that because your requirements are often set in a black letter law and you didn't buy a right kind of suite to be present where they were decided for the last 40 years.
> ...add edge cases as as later.” There's no permission really to say that.
I think there would be some value to closing that feedback loop to give legislators the signal "You know, what you're considering is actually pretty fuzzy conceptually... We're discovering while considering how to code it up that you probably don't actually have good, clear definitions for all the terms in this bill." But the biggest thing to remember about government IT is the clientele, which changes the approach from commercial / industry software.
Google can optimize for the common case. Google can cut the edge cases. Google can change APIs on a whim.
Google's users choose to be Google's users and can go elsewhere if they don't like it.
Government citizens don't have that choice. And in general, people don't lose access to their food if Google effs up. Or go without their legally-deserved unemployment pay. Or go to jail because their taxes were mis-calculated.
In the government space, the "edge cases" are human beings, alike in dignity. The rules and policies end up complicated because human beings are complicated. And yeah, it ends up being some messy software. Because you can't just decide to ignore the law when it's inconvenient to plumb the information that the client has a child under the age of 18 who is not a dependent because they're an emancipated minor, but said emancipated minor does have a child of their own, and the client is the primary caregiver for that child while her parent is in prison... from here to there in the dataset.
>Because you can't just decide to ignore the law when it's inconvenient to plumb the information that the client has a child under the age of 18 who is not a dependent because they're an emancipated minor, but said emancipated minor does have a child of their own, and the client is the primary caregiver for that child while her parent is in prison... from here to there in the dataset.
That's all very true, but nobody ever codifies that. When the data doesn't fit the constrains of the form that aims to handle a reasonable generalilized case, you simply get a phone call from a human in the loop. That human has a supervisor and you can also go to a court when they write your name with E instead of É and try to bullshit you about some kind of ASCIEBCDIC nonsense like it's real.
In the end you have one dataset which tells who is a child of who, another telling who has custody rights and a third one making sense of amounts and recipients of childcase subsidies. Maintained by different departments and eventually consistent or maybe not.
My interpretation is a little different. We agree that humans are affected by the edge cases, although I believe that's also true at very large companies like Google or Meta.
I don't think it's about avoiding programming 6700 edge cases, but more so that when you have an excessive number of cases, it's likely an indication that something is being missed. that could be due to a bug in software or due to unclear definitions in the legislation.
in those cases, rather than attempting to program it exactly, it might be better to bring a human into the loop.
and to me, that could be the point of having a tighter feedback loop. because otherwise the developers will just do their best, which will be buggy or incomplete. because they can't not do their job.