alt Hacker NewsCOBOL has been “dead” for so long, my grandpa wrote about it
Comments
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).
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?
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.
COBOL is not dead, but it's difficult to get access to, because there is almost no open-source tooling around it for Linux. We (OCamlPro) have created a project, called SuperBOL, to create an open-source environment around the GnuCOBOL open-source compiler (that is now very mature and used by companies). We have already released the VScode extension with an LSP for COBOL to get a modern IDE, and we are working on other tools, mostly depending on our customers.
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.
Cloud is the new mainframe, except worse. It has all the downsides, but does not have the biggest upside.
The grandpa could create (using CICS), a very reliable and performant service that would call other services inside the same transaction. The platform would handle all the complicated stuff, such as maintaining data integrity.
Try to write AWS Lambdas that call each other within the same transaction.
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 {
"EVEN"
"ODD"
println!("The number: {}", result);
COBOL:
display 'Enter number: '
accept number
if function mod(number,2) = 0
move 'even' to result
move 'odd' to result
display 'The number: ',result
Tangentially, I love this tweet:
https://x.com/grauhut/status/1000017084435312642
Translated:
> "I found some COBOL at a customer site. Fine. Mainframe. Nothing special. > The last comment is from 1985. > Written by my mother."
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.
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!
In case anyone is interested...
The SO Developer Surveys give some info on the job market for COBOL as it appears on the average salary versus years-of-experience graphs, which I like as there's as many stories or reasons as you can think of to explain them.
In 2023 there were 222 respondents who averaged 19 years of experience, and an average salary of $75,500. In 2024 the exact number of respondents is not shown, but likely similar based on the color code of the point, but the average experience had dropped to 17 years.
Elsewhere in the graph my favourite open question is: how come the over 2000 respondents mentioning Swift average over 11 years experience in a language that's only been public for 10 years?
2024 https://survey.stackoverflow.co/2024/work#salary-comp-total-...
2023 https://survey.stackoverflow.co/2023/?utm_source=so-owned&ut...
I'm very late to this post, so I'm sure this will get lost, but in case OP sees it, I'm very sorry for the loss of your grandparents, and hope that you found some joy and comfort in writing about your grandfather fondly in this article, and he has found peace after the loss of your grandmother.
Oh, btw, COBOL has the 2038 problem and it is right around the corner. We're going to need A LOT of new COBOL engineers to fix it. It runs so much of our world. We managed to save the world from Y2K in the nick of time. But, I'm not sure if we're going to have the minds necessary to solve 2038 by then as the can has just been kicked down the road without consideration. If anyone is worried there won't be jobs, there WILL be jobs.
Not to be too macabre, but we need to transfer the knowledge while the people who have it are still alive, can remember and can teach others to pick up the torch. And, let us call it was it is, of those remain and still have the desire to make the effort to transfer that knowledge.
It is easy to look back on y2k and think well that wasn't a big deal, but the only reason it wasn't is because people tirelessly worked to stop it. It is a testament to their success.
Regarding y2k Robert Bemer tried to warn people in 1971, with 29 years left to go. And, Peter de Jager published his attention-getting article "Doomsday 2000," in 1993 (in Computerworld), with a mere 7 years left which finally put the fire under everyone's ass. Keep in mind, there were still many original COBOL programmers and mainframe experts left to talk to at that time. And, there was a lot less code to change back then than there is now.
Voting tabulation, insurance, utilities, administrative systems, banking, ATMs, travel, healthcare, social security, point of sale, IRS, pension funds, TACTICAL NUKES, hotel bookings and payroll programs. More than 800 billion lines of COBOL code in production systems in daily use. For better or worse, it is the very bedrock of our modern society.
If you want to replace it with something that you want to maintain instead, that's fine too but we're running out of time.
"Danger, Will Robinson! DANGER!" https://www.youtube.com/watch?v=OWwOJlOI1nU
"Listen the nothing will be here any minute. I will just sit here and let it take me away too. They look... like... big... strong hands.... Don't they?" https://youtu.be/symP4QT7wLU?feature=shared&t=24
(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/ )
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.
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!
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.
condolences to the writer on his grandads passing.
It is a bit of a reality check when words like 'grandpa' are linked to an article from 1992! My brain is expecting the article to be from the 60's, 70's... or possibly 80's.
My world view, it is hard to image a child born in 2000 is 24 years old now. Their grandparents could be as old as I if they had children (and their children) at a young age.
Then I read at the end he was 91 when he passed. He did well! Likely around my Grandads age - and managed to last an extra 24 years on this planet!
I remember reading a book on COBOL in my younger days learning to program, alongside BASIC, C, and Pascal. I might still have it. Despite reading and never coding in it, I have been (fortunate, I guess) to have never programmed in it.
I do agree with the writer that using the word "dead" in the programming language world is unrealistic. Some would argue that there are popular, modern languages out there as being "dead" - but they might get a huge push for one reason or another in the future. Could COBOL find a new, niche spot.
Maybe.
When I was in college, I knew a guy who got an internship at Wells Fargo writing COBOL. He hated it.
The punchline is that this was in 2018.
COBOL is dead, long live COBOL.
For any cobol devs here, we at https://cobolcopilot.com would love to hear from you
I worked for a while as a contractor for the US Dept. of Education Student Loan system. It was z/OS with DB2 and most new business logic was done in this weird language "Gen" https://www.broadcom.com/products/mainframe/application-deve... . Gen can supposedly "generate" java and other stuff but they used it to generate COBOL for the mainframe. You could debug the Gen code on the 3270 emulator, rather than trying to deal with the generated COBOL. There were a small number of people (like 6) who were handling that code. The data and I guess some of the code went back to like 1980 at least. There was so much legacy code, I doubt they've changed platforms. I was supposed to be more a Java guy but I did a little Gen. Mainframe is very alien to me. The people that knew it well could really crank on it, though. I joined when they were converting an MS ASP front end to a Java one. So we wrote Java that users interacted with via the web and that made calls to Gen (really, to cobol). In retrospect there was a lot wrong with that operation... One interesting problem that came up once was that the mainframe didn't sort things the same as Java. It turned to be caused by EBCDIC vs UTF.
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.
20 years ago I worked on a mainframe system that, at the time, was said to have "18 months to live". Fast forward to today, the system is more entrenched than it ever was, and still has "18 months to live".. I'm convinced it will outlive me, and probably the next generation too.
> such as fourth-generation programming language (4GL). If you’re not familiar with that term, suffice it to say that the Wikipedia page lists several examples, and Cobol has outlasted most of them.
I'll have you know I was approached for a FileMaker project not too long ago!
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.
COBOL is dead? Not at all. Are new projects created in COBOL? Yes they do. If not in older COBOL form, definitely in SAP ABAP.
For those who haven't heard about it, ABAP (Advanced Business Application Programming) is the name of SAP’s proprietary, fourth-generation programming language :) It's SAP's main language. It's a direct descendant of COBOL, I'd describe it as a COBOL with OOP extensions.
Since SAP's ecosystem is sneaking everywhere, COBOL in its modern, very close incarnation (ABAP), gains new space!
If in any doubts, check some ABAP code. It's not simply influenced by COBOL, it's COBOL.
COBOL is endangered, even for banks and airlines. Just look at the executives who see decide to open new digital banks - they're not building on top of COBOL or mainframes. The old banks will be outmaneuvered by the new ones, and eventually succeed them in the market.
The story of languages like COBOL isn't that a language is too deeply embedded to become too expensive to replace. It just means the replacement will happen at a higher level - the business itself, and will take more time as a result.
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.
This makes me feel old.
In '92 I was maintaining COBOL code for a custom written warehouse management system for a wholesale boat bits distributor. The company that wrote it had lost almost all their COBOL devs, and were all in on Windows NT application dev.
I hate to admit it to myself, but I am in fact _just_ old enough that I could have cs grad aged grandkids, if I'd had kids early and they'd also had kids early. :sigh:
So is it worth learning COBOL for someone just looking to make money or not? I've heard people say yes, you can make a lot of money being the code monkey to fix the governments' software, and no, learning COBOL will not be enough (you need specific insight to whatever you're fixing as well).
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.
I find it fascinating that the recommended environment for IBM mainframe COBOL development is... Visual Studio Code. IBM makes a plugin that lets you remotely edit COBOL code on the mainframe in your editor.
Guess COBOL is alive enough to warrant this kind of support.
Cobol is dead, really? Read comments and main article - "The code that controls our money" --
I read The Cuckoo's Egg by Clifford Stoll (highly recommend btw) published in 1989. I laughed out loud when he described Cobol as an antiquated language that no one wanted to support. In 1989.
My first job was programming an ancient COBOL system in a government agency riddled with outdated tech.
The only real upside was, COBOL is so wordy, it forced me to improve my typing speed!
With LLMs which programming language used becomes irrelevant. LLMs do not replace programmers yet but they do give programmers incredible leverage making these points moot.
I think many would dispute that its dead. Apparently more than 95% of ATM swipes and 43% of banking systems are written in COBOL. No idea how true that is.
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.
RIP. He is an old man with wisdom and a sense of humor.
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
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...
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.
COBOL programmers spreading fake rumors about COBOL being dead so they keep their $200k-300k salaries
Do open source COBOL programs exist? Just wondering since I see it mentioned occasionally here.
Huh, so it mentions 4GLs… what generation would we consider rust/kotlin/swift then?
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.