In these weird times, I have actually considered learning COBOL. It feels like a legacy sort of language because there are certain things that we've come accustomed to that aren't there in COBOL, like package managers. https://twitter.com/mainframed767/status/1247178141124055040

There's also a fundamental disconnect between folks that do mainframe stuff and folks that do more ""modern"" development work. Let me explain, because this is important to how we frame the situation with COBOL, and how we talk about a lot of things in business.

To summarize @pleia2, we basically put the mainframe folks in their own corner, let them stew for 30-40 years in their own pond, then tried immediately to yank them out of that pond and get our applications "Off mainframes".

Even moreso, we joke about mainframe languages. There's an idle contempt for them. What do I mean?

https://github.com/azac/cobol-on-wheelchair

Yeah, that's what I mean.

( For a good look at mainframes and modern devops tools and the kind of thing I'm talking about, see the awesome talk by @pleia2 at SCaLE 18x )

And really, that's where the end lies: There's this contempt, It's frustratingly common, and so the rift between folks that understand and work on mainframes and the folks that talk about modern development grows.

What's the solution? I'm not entirely sure.
One is to fundamentally kill the Computer Science degree.

Hear me out: CS degrees are actually worthless for software development.

I've met too many people who come out of modern CS degrees, with bachelors and masters degrees, who can't solve the following task:

write a simple four-function calculator. Each input is an integer or float, an operation, and another integer or float, followed with a newline.

This is not a complex task. It's a four fucking function calculator, something that is well understood. I'll even credit bonus points for scientific notation.

I'll __even__ take eval() as a solution.

On the other hand, self-taught programmers and those who come out of several Software Development degrees think about this, pull out lang-of-choice and implement it in maybe 30 minutes. It's a very simple REPL in most cases.

Killing the CS degree would mean making a software trade. There are already some places that have this, such as @CNMsuncats , where you are exposed to more than one paradigm and required to actually know what you're doing by the time you get out.

Killing the CS degree would be useful but let's also consider killing COBOL, the business proposition:

COBOL is expensive to maintain. It has a lot of moving parts and it has a very small pool of knowledgeable folk, making these sorts of things a problem.

Back to mainframes:

Part of the issue with mainframe stuff is also that there is a stupid high cost of entry. There's no scale-equivalent-cost of a low-cost ARM device for a mainframe.

Give me something that costs $300 or so, fits in a miniITX form factor, performs like a 360 or even a z9/z800, and comes with a license for z/OS. Make it super easy to get into at that low level.

Imagine: A Mainframe in this form factor

it doesn't need to be fancy, it just needs to fit on a desk.

And that's the really big reason why nobody really learns COBOL today: It's not accessible without a lot of work. But that leads to another part of the COBOL ecosystem that we haven't talked about: copybooks.

For those who don't know: COBOL's library system, copybooks, is roughly 10x more flexible than C's preprocessor.

But nobody knows about it. Except COBOL programmers.

And the lack of visible libraries is one of the reasons that it's hard to see past the murky surface of COBOL.

COBOL makes it very hard to write games, do certain things like image manipulation (is there a COBOL JPEG library?) and plenty more.

And thus we get to one of the cruxes of COBOL's utility and simultaneous tragedy:

It was built for BUSINESS. It's right there in the name

There is little, if any, free software COBOL outside of...

The OpenCOBOL/gnucobol compiler.

I did a cursory search and there was basically just that and some very close supporting libraries, some even targeting GTK and such. Not much else, though.

This has meant that most, if not all, of the COBOL world is buried under the realm of commercial work.

This is untenable for academia, and as a result, it's not taught. Academia needs lots of little transparent boxes that it can use to demonstrate what you're learning.

I'm intentionally glossing over the horrible code that most COBOL appears to have. One of my contacts in this weird world put it like this:

"COBOL is like Assembler and INFORM7 had a child. It has all the power of Inform but hampered by the complexities of Assembler."

For those unfamiliar: INFORM7 is a natural-language dialect of INFORM6 for text adventures. For example, this is a complete INFORM7 game, that will mostly* compile (since RTF is an essential part of Inform)

"Twitter"

Twitter is a room. "You are in hell."

So, to wrap this long ass thread up:

Should we kill COBOL? Perhaps, but lessen its weight.

Currently, COBOL has a bus-factor of about 200. For all COBOL programs in the world, 800 billion lines approximately.

So either

1) a radical shift in COBOL has to happen, and we need to have businesses evaluate what they're actually doing or
2) We need to find a better solution than having a stupid low bus-factor for things critical to our world.

Killing COBOL might well be the only way out of this, but it won't come instantly. Businesses who built their empire on top of COBOL won't have the time nor energy to migrate everything overnight.

And the fact of the matter is that COBOL came from a different time.

Part of what made C powerful wasn't the simplicity, it was portability. It was just enough abstraction that the actual hardware didn't matter. It was just enough that you could create the abstractions.

But COBOL had all the abstractions dealt with... You just needed to pick what abstractions you were working with.

The official standard allows for so many variants and optional parts that the language itself has too many loose parts and places where you get edge cases.

Take for instance https://softwareengineering.stackexchange.com/a/115687 

This sort of bad abstraction ends up showing in some of the deeper parts of the conversation. OpenCOBOL won't run your classic COBOL thing you've been running on an AS/400 for 25 years.

And finally, I think the most telling question is: Was COBOL simply a bad choice from the beginning, Nobody wanted to accept the truth, and the future has reaped the rewards? I don't know, but there are telling truths in the words of history.

From an interview, archived < https://archive.org/details/historyofprogram0000hist/page/262 >

"Did the COBOL committee seriously believe users could not handle grade-school math?"

It would appear that the fate was sealed by the infighting of the committee's own hands.

Over 60 years of infighting. Older than my father. From the time of my grandfather.

Perhaps now it is time to lay one of our oldest giants to rest.