I glanced at this and ended up spending 20 minutes reading it and I regret nothing: https://www.wealthsimple.com/en-ca/magazine/cobol-controls-your-money
(Mostly of geek interest: About the continuing survival/blessing/curse of COBOL)
@timbray
It's a story about technical debt. The contradiction between "COBOL democratized coding. Companies could take everyday people and train them to be useful COBOL programmers in a few months" and "the bank no longer employs anyone who understands COBOL as well as Thomas does" is a stark reminder that coding isn't the hard part of software development.
This. I learned COBOL in college. It's not super hard. The issue here isn't the language. The issue is "hey - we have a code base that is mission-critical, and has grown over the years, implements some ugly financial procedures that you may not understand, and none of the original folks who understand it are still around, and if you screw it up it could cost millions"- the language is *irrelevant*. I'd hesitate to touch something with those specs written in any language, not just COBOL.
COBOL and JCL are not difficult languages to learn.
The problem is that any given *system* is *thousands* of those programs interacting in all kinds of subtle and complex ways.
And that COBOL, as a language, is so limited that thousands of subtle dependencies between far-flung programs are inevitable. Finding all of them impossible. And any failure can kill the whole business.
@Biggles @dagon @timbray
Yes and no.
While I agree that the specific language helps only so much, some languages can still make a difference.
At least in my professional experience, onboarding new people on large projects written in a minimalist, type-driven language such as #elm was significantly faster than comparable projects written in #javascript, #java or #ruby.
It is also much, much more difficult for inexperienced people to make costly mistakes.