It might be difficult to find a substantial number of people who actually want to be trained in COBOL.

I myself can handle a lot of drudgery for $350k a year.

Good developers - those who like what they do - won't touch it with a stick. People do OCaml, Haskell, Clojure in their spare time and C# and Java at work - but nobody codes COBOL in their spare time. People code in Assembly, sometimes in hand-assembled hexadecimal format, but not COBOL.

It's a job, usually a boring one.

The language is just at tool; being fixated on OCaml or Haskell or whatnot seems like mistaking a tool for a goal.

I'd love the opportunity to work one of these applications. It's different from anything I've done before and all other things being equal is certainly seems more interesting than working on the 6162th ride hailing app or some ad-tech meaningless nonsense.

It also just so happens to be written in COBOL.

https://blog.carlmjohnson.net/post/2017/what-kind-of-program...

THAT is true of any language, the fact that COBOL has divisions does make it a bit easier. But you can also do very structored code in COBOL and code without using the GOTO verb. However many systems and code born the scars of the time. Fast code really did make a difference and was measurable in cost a lot more upon an expensive mainframe and when your processing near on a million records, very noticable in costs. So GOTO got used a lot, as coding for exception handling using structured programming like JSP (Jackson Structured Programming - the thing in the COBOL days) whilst doable, wasn't the fastest code and equally, not that readable if you didn't know the methodology behind JSP.

But over time you don't see the language, you see it from a data perspective and with that, code however laid out becomes easier to manage and by that, anybody else's code will look a bit yuk to you. Indeed it is rare to work on somebody else's code and come away with a warm fuzzy glow.