Yeah, I learned COBOL for sort-of-fun (in the sense that it wasn't strictly for a paid gig) a long time ago. It went pretty well, in that I learned that, while

Yeah, I learned COBOL for sort-of-fun (in the sense that it wasn't strictly for a paid gig) a long time ago. It went pretty well, in that I learned that, while it isn't a fun language in any sense of the word, it Just Works and even adheres to the revered Unix principle "do one thing, and do it well" in most production situations. Most COBOL programs have a very well-defined batch-oriented flow: take this file, process it, then output these file(s) within N hours. Reliability is paramount: batches often run overnight, and you don't want operators getting angry with you. And there is an entire ecosystem, all consisting of proprietary (and expensive) IBM solutions like CICS, that make CRUD apps (which, admit it, is like 80% of all software...) pretty much a piece of cake. The downside of all this, is that you're very much limited to whatever your vendor allows, that progress is glacial, and that innovation is pretty much unheard of (since that might break the batch, which is... a mortal sin). And, like with the Unix philosophy, orchestration of all those single-minded processes becomes an issue after a (short) while. If anyone were to ask me whether they should "learn the language", my answer would be an unqualified no, unless it's for a specific paid assignment. There are no unique ideas hiding anywhere in COBOL that are absent from more modern (and more 'fun') languages. But does it matter to learn the language paradigms and orchestration requirements? Sure: you may land a good gig if you understand where AS400s/i-Systems/whatever fit in, and it may give some insight into where things like Docker and K8S are coming from.