[1] example: https://www.bloomberg.com/news/articles/2020-04-13/an-ancien...
[1] example: https://www.bloomberg.com/news/articles/2020-04-13/an-ancien...
Well, yes, but as someone who works in public sector in-house IT, often tangentially around old COBOL systems and has been directly involved in systems replacements for some that had become unmaintainable, I sit on the “familiar” side of the Gell-Mann Amnesia Effect with those stories and recognize that they rely almost entirely on the accounts of people and organizations whose massive institutional failures they cover for.
They aren't unmaintainable because “COBOL”, but because of poor choices is contracting and contracting oversight as they were developed, both initially and with subsequent revisions, which leaves them both poorly architected for change and without useful documentation of functional/behavioral requirements, concrete design, or, really, much of anything else, with key knowledge trapped in individual people’s heads, scattered among business and IT initially, and almost all of which have since moved on, leaving behind a smaller set of people responsible for the system who deal with it through rote, cargo cult practices that they don't understand the reasons for. They'd be unmaintainable if COBOL was a currently-popular language.
If you look at the same institutions, .NET (maybe even .NET Core) apps that are comparatively in infancy, only a handful of years old, are following those COBOL apps rapidly down the same path, and have frequently already become difficult to maintain.
But an old language is a convenient scapegoat for deep and entrenched organizational dysfunction.
Here's a blow-by-blow from someone who was, at the time, dealing with some of these systems as part of the United States Digital Service, and thought she ought to get to know the beast up close. It's not pretty:
https://medium.com/the-technical-archaeologist/hello-world-o...
I think it's interesting you compare it to a punchcard, given that the 80 column limits and the fixed width layouts of COBOL (and FORTRAN) are entirely driven by punchcard layout.
I disagree.
"$" is understandable for just about every 2 year old on the planet[1] and understood by just about every developer on the planet, including the majority for whom English is not their first language. ("IDENTIFICATION DIVISION"? Why would you divide your name?)
"@" is understandable for a 6 year old.[2]
Calling such incredibly simple things "runes" and "exotic" is like calling "0" an exotic rune.[2]
[1] "$" is just a visual/audio/semantic/mnemonic/symbol overlaying S for "Single" and I for "Item". According to replicated scientific studies an average English baby demonstrates understanding of this concept at around 22-24 months. I think a conclusion that a 2 year old could understand "$" is reasonable.
[2] "@" is just a visual/audio/semantic/mnemonic/symbol overlaying "at" to indicate indexing, "a" to indicate "array", and "0" to indicate counting starts at zero. According to a 2018 scientific study[3] an average child has come to understand integer counting by the age of around 3 and a half, and is comfortable with counting from "0" at around 5-6 years of age. Perhaps the most challenging aspect is the notion of an "array"; but the whole point of having an "@" is to distinguish it from "$" without getting into details. I think a conclusion that a 6 year old could understand "@" more easily than they could understand addition is reasonable.
perl syntax is actually highly intuitive because it copies nearly everything from pre-existing tools, shell scripts, sed, awk, and so on. perl just packaged it all into one cohesive tool.
It was one of those languages where you barely need to read the manual because you can predict things because the syntax will be exactly what'd you'd guess it to be.
All this, of course, if and only if you had previously grown up on shell, sed, awk and friends. For anyone who hasn't, I can totally see how perl seems like alien gobbledygook.