Hacker News Reader

Comment by tjrgergw | Hacker News Reader

Does anyone want to comment on why COBOL has a reputation of being good for critical stuff? Are there technical reasons for this, or is that just branding?

View on HN

its not so much COBOL, its the mainframe environment that is brilliant for critical stuff. My company migrates mainframe applications to the cloud so we find all kinds of reasons for clients to move, cost/skills/scalability etc but the mainframe is a highly optimized platform for running mission critical applications. Its a different model 1 platform 99.9999% uptime vs the distributed cloud approach where you can have failures on any particular node. A lot of other stuff on the public cloud replicates and is inspired by the mainframe.

It isn't, but rewrites are always percieved as being more dangerous than incremental change. So you get systems with 50 years of incremental change on them.

The "old" language which actually might deserve the "good for critical stuff" reputation is ADA.

Not COBOL itself, but Mainframes/Z systems are known for their high availability/reliability. Mainframes have many hardware redundancies that help contribute to their fantastic uptimes, despite being a single unit. One might ask why a distributed system wouldn’t be better, which is a fair question. It really depends on what you are doing. This is where the CAP theorem comes into play. For situations where data consistency is a must, mainframes are a good fit. If you look at some of the notable examples of where mainframes are used, such as VISA transactions or banking, you'll see that data consistency is critical in these situations. Building a comparable distributed system would not be an easy feat.

Mainframes, especially modern ones, are pretty cool imo. The obvious downside is the high cost, which makes them very unappealing for startups.

There was a thread last week asking why cloud hasn't killed the mainframe, which I thought had some pretty good replies: https://news.ycombinator.com/item?id=37333837

The impression I get in some cases, is less that it's the best choice, but more that a lot of companies have decades of data or systems all inter operating with it, and migrating things to something modern would be a nightmare but they can't afford to lose the data.

Typical COBOL has no unit tests, no version control, and no "dev" environments, while handling millions of dollars. Touching this stuff is scary.

So if you are (say) IT director in the bank, and you value your career, you should reject all attempt to modernize, as all failures would be blamed on you. Just say something about COBOL being most reliable and ask for more budget for contractors.

Maybe simply because some critical stuff currently runs on COBOL. So it has stood the test of time. There may be languages/tech that would be just as good or better, but we know that COBOL can do the job.

Yeah, I think there's definitely a lot of survivorship bias involved. COBOL was IBM's biggest suggestion at the height of IBM selling every business that they needed a mainframe to run their core business. For a brief era "every company ran on COBOL [on IBM mainframes]" and those programs were core to a lot of those companies' success stories. As computers moved on, the programs that survived in COBOL were already critical to business success. Every decade fewer COBOL programs survive, leaving only the "critical" ones left. Tautologically that survivorship sometime implies that COBOL itself was a key ingredient that made them critical programs, but mostly they are just critical programs because they survived that test of time.

Reply on news.ycombinator.com