Has anyone ever actually met a COBOL programmer? It seems like the teachers tale of someone cracking their head open while swinging on their chair - presumably they exist but there can't be that many of them?
For example, I've got a decent-sized network and I've only ever met one person who works in government tech. And it wasn't through that network. But you can't tell me the government doesn't have legions of people working on its systems.
Even talking with this friend about work is like speaking another language. He builds, tests, and manages huge digital systems, but all of it is done using this product called Microsoft Dynamics, which I'd never even heard of. He doesn't really write any code, but the medium he works in is as complex and powerful as a programming language ecosystem. Yet there's almost no crossover between the jobs each of us might apply for. It's like an uncanny, alternate universe, coexisting with the one I live in. I think there are many such universes and it's entirely possible to go through your career without ever meeting someone from one of the others.
SAP is another ERP parallel universe, with its own language (ABAP), industry certification schemes, conferences, publications, culture...
These vendors specialize in solving the nexus of unfun problems that sit at the heart of every large organization (invoicing & expenses, accounting, payroll, budgeting & forecasting, financial statements…) and I believe them to be quite well insulated from the forces of open source and consumerization that have shaped the wider industry, because there is no consumer/hobbyist path to creating an alternative. Workday has come closest.
I think one of the biggest impediments is that the audience is highly risk-adverse, and the problem domain is highly risk-prone. There's an enormous incentive to go with an industry "known good" even if you know you're getting thrown over a barrel.
ERP conversion are highly, highly likely to fail in terms of on-budget, on-time (more so than the general abysmal record of IT projects). Lack of business ownership/knowledge of processes and requirements is usually at the heart of it, IME. I've been through a couple SAP implementations, a couple SAP upgrades, and conversions to other platforms in my earlier life (Deltek, Dynamics), and they are truly the worst projects on the planet to do.
In the government contracting space, Deltek (which most have never even heard of) is such a winner with accounting departments because they're playing to government auditors - the level of scrutiny from just saying "we run Deltek" compared to some roll-your-own solution is miles of difference and ultimate cost. I don't have any relationship with or love for Deltek, btw, this is just my IRL observation and an example of what the "customer" is thinking about - they could care less about technology stack.
I think most finance departments just "mind the machine" they have - it's really rare (again, IME) to find people in a finance department who have expert knowledge of the key business processes, report audiences/dependencies, and how everything ties together. You can throw a ton of business analysts at it and still find dark corners that went unaddressed after or the night before go-live. And you're impacting things like payroll, benefits calculations, vendor payments, invoicing, taxation, etc. High risk stuff to kludge up.
For example: Hedge fund traders, Game Engine lead devs, scientists, profession esports players, aerospace engineers etc.
I particularly enjoy that D has given a bunch of smart people with no qualifications a venue to do what they love and get paid a small fortune doing it.
That being said, I like languages that came later much more, and absolutely would not choose to create a project today using it. I also wrote a lot of Pascal in the 80's, then moved to C/C++ and Python. Python is the language I've used the most in the 2000's, but now I'm studying Typescript, and think that is a perfectly fine language which I plan to use professionally. I've also studied OCaml and Rust and would absolutely choose the latter now for anything where efficiency was a prime requirement.
I've met quite a few. I spent a year in a mainframe team in Amex and I worked in COBOL, JCL and REXX. I preferred REXX, but COBOL is not that bad. JCL is a horror. I worked in that team in 2016. The median age in the team was around 40 ish but there were a few outliers, including myself and a couple of others. I was also acquainted with many dozens of third-party contractors who worked for Amex programming mainframes.
If you haven't met many COBOL programmers yourself, the reason might be that a) you've never worked in a big financial corp and b) you don't hang out with programmers from big contractor companies a lot.
To clarify, most of my career in the industry before and after that I was working with more modern languages, like C# and Python.
Almost all of them were older than 50 though.
Probably most governments still have them. Social security and health payments from governments probably go through Cobol code.
Pleasant, relaxed bunch.
Nowadays a "mainframe" is just a 1U server and it's incredible how some old names in IT can still charge enormous fees for some very old software.
No it isn't. But I grant that there are probably people who incorrectly call their 1U servers "mainframes".