The article even mentions Visual COBOL which is a COBOL compiler to the .NET CLR so you can mix C# and COBOL in the same applications. You can look at the .NET

The article even mentions Visual COBOL which is a COBOL compiler to the .NET CLR so you can mix C# and COBOL in the same applications. You can look at the .NET IL disassembly with tools like ILSpy and even get a sense of what the equivalent C# code would look like (and my understanding is that it mostly looks like garbage and nothing like what a good C# library would look like). One perspective on COBOL and why it is such a "write only" language is that it's barely a stone's throw from an Assembly Language with a verbose BASIC-like phrasing. (Well, historically BASIC derives from lessons learned from COBOL rather than the other way around, but from a modern perspective you get the gist.) Every single line has the readability of English, sort of, with that BASIC-like face. Every single line has just about the simplicity of your average basic processor op-codes, just like assembly. To do anything reasonably complex you need lots of lines building up layers of complexity from the simple instructions, just like assembly. Trying to figure out the high level control flow and analyze the overall logic, just like in any disassembly effort, becomes a mind's eye puzzle because there's few ways to visualize the abstractions in the code because the code is at too low of a level for good abstractions. There's no functions and classes, just lots and lots of little instructions. Endless instructions.