Hacker News Reader

> Most of the COBOL being written today is for maintaining legacy code, not starting new projects.

Funny thing, I worked on a project with a mainframe division, that replaced a crusty old COBOL-based mainframe app with... an RPG mainframe app. In the 2010s. Ostensibly because we could leverage existing knowledge from other divisions under the same parent company, but really because of politics, as these things normally are.

View on HN

There's also some practical reasons for keeping a program on the mainframe. I currently work in mainframe development at a large company. We're in the beginning stages of "modernizing" some of our mainframe applications (moving the user interface from CICS to the web). The main workhorse processes will still be on the mainframe, and for good reason: it's a goddamn powerhouse. Should we get a high volumes, we can give the processes some extra CPU's and MIPS, and it'll chug along even faster. It's a bit more difficult to provision extra VMs for a distributed server environment in order to do such things.

Plus, for all of COBOL's faults, it's simply more efficient for "business-y" processes. All anyone cares about is manipulating data found within a file or database, and that's what COBOL excels at.

Reply on news.ycombinator.com