I started recently to learn Cobol, since 2 companies my friend and son were working at need them desperately. They would prefer people with experience in the bankiing/finance industry, but at this point all the over 60s guys are leaving, and nobody is left to pick up the mantle. They told me even though the money is great >$225k starting, people don't want to maintain legacy Cobol code with very high risk if you mess up.
The language is actually relatively modern, it kept up with time (latest ISO version is from 2023), and there are even IDEs like Rocket Visual COBOL, granted not something that you might get on e.g. z/OS, but there are others.
It actually compiles to native code, it handles well its use case, batch processing business data, and despite everything less verbose than most agents markdown files I keep seeing.
Yes the risk is there, but it is also there for any kind of legacy application in enterprise scenarios, which is why most migrations fail.
I'll have to dive back in. I could use the decent salary right now. I've been out of work aside from my endeavors to bring this hoist to market we are working on currently. The whole formal verification thing has become an obsession of mine lately. First it was applied to just the safety-critical aspects of our system. Now, I am applying lesser, but still powerful methods and tools to make sure the whole front end and basic networking is also part of this formal verification chain. Down the rabbit hole!
Refactoring legacy code seems like something where formal methods could help. "Prove that these 2 subroutines are equivalent, across all inputs" is exactly the kind of thing that they're good at!
Comments
I think in 2026 complaining about verbosity is a moot point, when folks are programming writing book sized Markdown files for AI tools.
Heck, even complaining about COBOL programming feels like a joke now.
Kudos on you Ada adventures.
I started recently to learn Cobol, since 2 companies my friend and son were working at need them desperately. They would prefer people with experience in the bankiing/finance industry, but at this point all the over 60s guys are leaving, and nobody is left to pick up the mantle. They told me even though the money is great >$225k starting, people don't want to maintain legacy Cobol code with very high risk if you mess up.
The language is actually relatively modern, it kept up with time (latest ISO version is from 2023), and there are even IDEs like Rocket Visual COBOL, granted not something that you might get on e.g. z/OS, but there are others.
It actually compiles to native code, it handles well its use case, batch processing business data, and despite everything less verbose than most agents markdown files I keep seeing.
Yes the risk is there, but it is also there for any kind of legacy application in enterprise scenarios, which is why most migrations fail.
I'll have to dive back in. I could use the decent salary right now. I've been out of work aside from my endeavors to bring this hoist to market we are working on currently. The whole formal verification thing has become an obsession of mine lately. First it was applied to just the safety-critical aspects of our system. Now, I am applying lesser, but still powerful methods and tools to make sure the whole front end and basic networking is also part of this formal verification chain. Down the rabbit hole!
You might find the paper Verification for legacy programs by Michael Ernst useful - https://homes.cs.washington.edu/~mernst/pubs/legacy-verifica...
Also see Round-Trip Correctness: A New Metric for Generative AI-Based Process Modeling - https://news.ycombinator.com/item?id=49033317
Refactoring legacy code seems like something where formal methods could help. "Prove that these 2 subroutines are equivalent, across all inputs" is exactly the kind of thing that they're good at!
https://news.ycombinator.com/item?id=49646528