This seems to be a marketing piece from Microfocus, it doesn't really say much.
> Easy to Understand, Anywhere You Like
Cobol is trivial to learn, read and write. The difficulty comes from the lack of abstractions and sheer volume of legacy code. Lets be clear, there is virtually zero green field development using newer Cobol standards, and the vast majority of code out there are the massive Cobol 85 applications that have evolved over decades to encompass and encode processes for entire industries.
We've consistently seen reports of a shortage of Cobol developers the past few years. Cobol applications are cost centers and the companies that have them have been seeking to minimize their costs for a long, long time. Over the past 20 years there have been waves of offshoring that have gutted the ranks of the system experts. There are tens of thousands of laid of Cobol developers in the US alone. The jobs went offshore. The only shortage is in Cobol developers with domain expertise, precisely the ones that were fired many years ago, who will work for low wages on offer.
It does however, perhaps conveniently, ignore the complexity of the COBOL runtime environments like VRX, CICS etc from mainframe days. One think I like about GNU COBOL is it transpires to C and then compiles that. So you can run in most of the modern nix environments.
Programming in COBOL is beyond tedious. My encounters with COBOL was as a system programmer fixing stuff COBOL programmers didn't understand about the operating system.
My other involvement was teaching SQL to COBOL students.
FORTRAN shares with COBOL the mantle of the first compiler languages. As pioneers, they were stunted.
I remain a fan of PL/I for applications. It learned from the limitations of the early languages, but too many managements wanted to keep things stupid simple.
Mind you, PL/I would happily allow you to program in inefficient ways with serious performance costs.
You require knowledge of the code the compiler produces and which parts of the subroutine library are best avoided before you can promulgate standards for production applications.
It's been a couple decades since I had a need for PL/I. Mostly I used Assembler for working with the operating system and channel programming.
PL/M last I looked was not allowed outside IBM development labs, but I see a bunch of stuff coded in PL/M. My impression is that it's basically a bunch of macros wrapped around Assembler instructions in a common quest to eliminate branch instructions.
But remember that every IF and loop is implemented with branches under the covers.
One of the great things about COBOL is that it is really simple to learn and use. I wrote the only two COBOL programs I ever have (and I certainly don't want to write any more, but they were easy) which exctracted data from a CODASYL database, after flicking through a COBOL textbook for a couple of hours. This was back in the 1980s.
The real problem with learning COBOL is the surrounding infrastructure, such as CICS. Now, that is a bugger.
I touched some cobol on the side. My experience is these people are business knowledge keepers first and developers second.
The language capability and their tech level was extremely low. I got superpowers like grepping the full code base for a thing to refactor, or writing an sql select statement that could query a whole table at once, instead of just 1 record. Otoh, I ran into trouble when trying to integrate an url longer than 1 line of 80 chars. Non ISO8859-characters are still impossible over there.
Their superpower was explaining what the business actually did, what edge cases were forgotten,...
The unfortunate truth was I was easily replacable with any dev from the last 20 years, if only someone wanted to actually talk to them instead of stonewalling them for their incomprehensible elder rituals. And I got paid a lot better, too.
Ah, yes. We were due for another article about COBOL posted to HN. Then the corresponding myth about how that's where the big money is, etc.
It is my mission to remind people who might buy into that myth that COBOL is a clunky, boring language and that it's also not true that's where the easy money is.
I learnt COBOL in 1981 and started my IT career programming in it. Fast fwd and I still have not seen or use a better business DSL. Use it as it was intended, for business applications, like accounts and payroll, and ERP, and you find it a delight - easy, simple.
My experience may be similar. I started programming in COBOL in 1979 - 1980 timeframe. I was working in Seattle, Washington, using Ryan-McFarland COBOL on a Texas-Instruments DS-990 computer system. I thought it was a good programming environment. We were writing business accounting software and it all worked really well.
I wrote my first production program in COBOL back in 1983 at Hewlett-Packard.
It basically took reports formatted for the multi-carbon “greenbar” paper that normally went to the big dot matrix printers and sent them instead to print on the then-new HP2680a desk size laser printer.
They made me emulate the look of greenbar paper on the white fanfold laser prints because that was what people were used to.
Title seems a bit click baitish - the latest COBOL standard is from 2014, not 2022. It has added such useful features to the language as IEEE 754 floats and dynamic capacity tables. Not sure if there's any work ongoing for a future standard, or what further additions that might entail.
> Easy to Understand, Anywhere You Like
Cobol is trivial to learn, read and write. The difficulty comes from the lack of abstractions and sheer volume of legacy code. Lets be clear, there is virtually zero green field development using newer Cobol standards, and the vast majority of code out there are the massive Cobol 85 applications that have evolved over decades to encompass and encode processes for entire industries.
We've consistently seen reports of a shortage of Cobol developers the past few years. Cobol applications are cost centers and the companies that have them have been seeking to minimize their costs for a long, long time. Over the past 20 years there have been waves of offshoring that have gutted the ranks of the system experts. There are tens of thousands of laid of Cobol developers in the US alone. The jobs went offshore. The only shortage is in Cobol developers with domain expertise, precisely the ones that were fired many years ago, who will work for low wages on offer.