> "Beauty" and "COBOL" do not mix in the same sentence.

The author is falling into the trap of assuming that “easy to learn” = “optimal”. COBOL is extremely easy to learn; you can learn it in a few days. That simplicity comes at a price: you outgrow it _really fast_. You can’t even write a generic sort routine or a linked list data structure in COBOL; the language just doesn’t allow that sort of reuse. I thought it was almost comical that the author had so little experience with COBOL that he wrote that it allowed you to not repeat yourself: the painful experience of rewriting things like sort routines every time you had a different comparison condition or rewriting linked list traversal code when you had a structure with a different schema than the structure that you last wrote linked list traversal code for was the reason everybody started abandoning COBOL for more flexible languages like C (even Pascal was better).

I won't argue the merits of COBOL. I stopped doing it for a living 35 years ago for a reason, but sort is not a good example. COBOL has generic SORT and MERGE facilities built in as verbs. In an IBM environment (i.e. writing real applications) you'd be hard pressed to build something that has better performance than what's provided out of the box.

Those were good for working with flat files and nothing else!

You don't need sorting for VSAM or DB2 or their non-IBM equivalents.

Exactly right; all the Cobol jobs went offshore over the past two decades. There are 1,000s of former Cobol developers in my area alone. Cobol is a cost center companies seek to minimize.

All this talk about Cobol and nothing about it's characteristics that make it truly remarkable: all memory is statically allocated, there is no dynamic memory allocation. Makes streaming xml processing a true nightmare, but also make Cobol applications immune to entire classes of security vulnerabilities and exploits that plague every other language. Also, make performance reliable and easy to reason about with none of the "departures" common in other runtimes (ie thread pool exhaustion, stack overflow errors, heap exhaustion errors). Really dependable from a day to day management perspective.

There's this rather sad thread from a decade back of cobol developers discussing being stranded after the jobs dried up.

https://www.indeed.com/forum/job/Cobol-Developer/other-non-c...