The former is also still going strong; the US Social Security Administration has sixty million lines of the stuff (as well as half of banks and approximately 80% of card transactions).
COBOL, at this point, has outlived Dijkstra and is poised to be a language-in-use for longer than he was a human-in-breathing. So I suspect he missed the mark on that one.
(I think, personally, we hackers have a bad habit of deciding a language that doesn't fit our favorite problem domains is a bad language. There are reasons, other than simple inertia, that COBOL sticks around in places where the main task is turning written laws into computer code...).
I don't consider COBOL to be a good indicator of programming quality. Although frankly, I will say that about most software. Generally products stick around not because they're good but because replacing them would be too costly. And generally products get in not because they're good but because they're decent and get lucky with timing. I saw another HN post today about Excel. I think Excel is on the better end of the software spectrum. Still, the main reasons why we don't yet have "Excel++ but for real better" everywhere is simply because developing such a thing and then getting the traction for it would be infeasible. I will once again say that I don't consider COBOL remotely impressive for still underlying many important computer systems. The computer systems are important because of their purpose, and implementation is always a conflict with purpose.
> don't consider COBOL to be a good indicator of programming quality
COBOL wasn't designed for that. The intention was a language that non-coders could code in. This was the precursor to things like FIT which was a precursor to today's Cucumber, like some history of child abuse carried on over the generations, so we still suffer today.
COBOL, at this point, has outlived Dijkstra and is poised to be a language-in-use for longer than he was a human-in-breathing. So I suspect he missed the mark on that one.
(I think, personally, we hackers have a bad habit of deciding a language that doesn't fit our favorite problem domains is a bad language. There are reasons, other than simple inertia, that COBOL sticks around in places where the main task is turning written laws into computer code...).