Earlier quoted context omitted.
Most Oracle "shops" i know have used it for decades. When they started using it, there weren't many options, so Oracle was what was used. COBOL is in the same category. When invented, it was the absolute easiest programming language to learn and use, so of course it gained popularity. It then turned out to be rather good at what it did, along with running on hardware that "never fails", so most places didn't even thi…
> young people not taking an interest in COBOL and Mainframes It is more like young people not wanting to: - throw their careers out of the window by pigeonholing themselves into zombieware tech - experience high levels of stress trying to debug code older than their parents, writing code that can't be unit tested and pushing said code to production
The only language that comes even remotely close is Java, in terms of job guarantee.
I doubt it's more stressful. Debuggers absolutely do exist, as do modern desktop editors with step by step debugging, but you will have to learn at least a little bit about memory management, SQL, and other "nasty relics".
It appears to be a part of the skillset that is no longer taught. I've worked in the embedded industry for a decade, and we usually had little more than trace lines over a serial cable to debug our code, and yet we somehow made it work.
I've long since realized that being a skilled programmer has very little to do with what language(s) you code in, and more about your understanding of the problem space. Yes, you can be a star in Advent of Code if you know every nook and cranny of your chosen (esoteric) programming language, but often people that understands the business side of things will fare much better.
And yes, I've also been young once, and I've programmed in just about every programming language that has been "modern" or "old" in the past 30-40 years (I've even written software in APL), and I've been good at it. I also absolutely despised the thought of programming in COBOL, but in the end, programming is about telling the computer what to do, and the what is the important part, not the how.