Looks like some of us old computer timers (programmers, system developers, etc.)
will have a job forever more, if we want. This blurb about COBOL being so dominate still, 60 years later, is surprising some (not me). The reason it wasn't surprising to me is that it costs money to come in afterwards, and rewrite code, and some things written in old code still does a better job. Nice to have job security, eh?
60-year-old programming language understood by fewer and fewer developers underpins many more applications than previously thought, new data suggests.
According to a report from IT modernization company Micro Focus, there are currently more than 800 billion lines of COBOL code in daily use across the globe, roughly three times more than anticipated.
Whats more, almost half of the developers surveyed actually expect the volume of COBOL in their organization to increase over the next twelve months, while a similar proportion say they expect COBOL applications to live on for at least another decade.
The typical narrative surrounding COBOL is that the waning number of developers familiar with the language has the potential to cause significant problems, due to the variety of mission-critical apps it props up in sectors such as government and banking.
Article in Tech Radar, dated Feb. 4, 2022
they speak of it like its some mystery language lost in the mists of time. Surely there are ways to teach it to young programmers. Its not exactly linear B
five days a week. There were other things mixed in too, such as JCL, Utilities, etc., but one could learn it rather quickly (like the other languages).
I think kids are all going for the 'romantic' languages, those involved w/ website development, etc. I talked to one kid (30 years + in age) recently, and when I mentioned all of the languages I had coded in, he called them 'antique'. Ha ha heh. I got a laugh out of it.
He coded in Python.
Most old-time programmers (like me and perhaps you) know probably 10 languages or so, we had to, depending on what one had to do. I recall one that we had to read a magnetic tape (assembler and Fortran), the ascii binary data read off the tape was then converted into 4-byte records via a COBOL program, and then we had a user interface (COBOL and PL1) which massaged the 4-byte chunks into billing records for downstream processing by various systems.
programming websites back in the day.
I took a COBOL intro class in college[*] and didn't think it was all that difficult.
(Of course, the same could be said for any programming language. They're a lot like chess: basics are easy; mastery takes time.)
There are free courses available, such as this one from IBM: https://www.ibm.com/blogs/ibm-training/free-course-announcing-learning-cobol-programming-with-vscode/
[*] - Funny story some of the regulars might appreciate: On the first day of class, the instructor emphasized the importance of good structured programming practices, including descriptive variable names, useful function names, and so on. "I don't," he said, "want to see any program flow that goes: 1) initialization, 2) a miracle happens, and 3) results."
Now PERFORM was a keyword in our version of COBOL. It called a subroutine (IIRC).
Fast forward to the final project and (of course) I named the central "black-box" routine "A_MIRACLE"
Which of course meant that "PERFORM A_MIRACLE" was the calling line. Naturally, the line above was "PERFORM INITIALIZATION" and the one below was "PERFORM RESULTS".
I got an A on the project and later asked my teacher what he thought of my little joke. "Huh? I didn't even notice it."
(Le sigh. Story of my life, really.)
Cobol II was the rewrite IBM put out for Cobol I. It was a pain in the blank, we had to rewrite a lot of older cobol programs to be compatible w/ the new vers. of cobol. That didn't happen until the mid-1980s at minimum. Sorry about the confusion. Perhaps you have a future job in coding?