Your feelings regarding the language being designed for use by accountants/corporate are completely correct. COBOL was originally designed to be very verbose for this exact reason (i.e. to make COBOL programs accessible/readable for business folk).

I’m a programmer but personally I like the verbosity of COBOL. I like self-documenting code. The code I write in other languages often ends up being pretty wordy too. Certainly there can be a long debate about how verbose programs should be.

I wouldn’t say that COBOL is terrible and deserves to die for this design decision though, especially when it outperforms other languages in the places that really matter (i.e. doing business transactions quickly and accurately).

For what it’s worth, it’s possible to make COBOL less verbose. Standard COBOL syntax is still getting updated (iirc the last standard COBOL update was in 2023). These updates have often made keywords that were otherwise mandatory before optional. If you add COBOL dialects to the mix you can get code which is very similar to other languages depending on which dialect you choose.

In what way is it terrible?

When it comes to COBOL developers, there are a lot of developers retiring but there are also a lot of programmers being trained in COBOL every year. It’s for this reason that the average age of COBOL developers has stayed roughly the same for the past 2 decades despite retirements. But that said the total number of COBOL developers is decreasing.

It is certainly an issue. Not many young programmers want to learn COBOL. COBOL isn’t taught in many educational institutions. There are very few online resources that programmers can use to self-teach COBOL. More often than not people are trained in COBOL by their employer. I didn’t know how to program in COBOL until I started at my current company (and even then I stumbled into this position accidentally because I wasn’t aware that junior developer jobs in COBOL existed when I graduated university).

It’s a shame.

I’m a COBOL developer. For old COBOL systems it’s not just a case of it being expensive to “migrate away”, it’s extremely risky and for no significant benefit.

Businesses have essentially two options, modernize what they already have, or tear everything apart and start from scratch. COBOL programs don’t “just work”, they’re good at what they need to do (business transactions). Therefore, there isn’t a significant need to rewrite everything, especially when it’s possible to modernize and reuse existing business logic contained within COBOL programs. For example, COBOL programs aren’t tied to old hardware, you can run your COBOL applications on the cloud instead. This is much safer and cheaper than rewriting everything.

Not allowing users to access a service at all unless they accept cookies is often against GDPR. See: Can we use ‘cookie walls’?.

To quote:

In some circumstances, this approach is inappropriate; for example, where the user or subscriber has no genuine choice but to sign up. This is because the UK GDPR says that consent must be freely given.

If your use of a cookie wall is intended to require, or influence, users to agree to their personal data being used by you or any third parties as a condition of accessing your service, then it is unlikely that user consent is considered valid.

The key is that individuals are provided with a genuine free choice; consent should not be bundled up as a condition of the service unless it is necessary for that service.

These cookie banners often violate all sorts of GDPR rules even more explicitly than this example. For example did you know it’s not allowed to have pre-ticked boxes on cookie popups for non-essential cookies?