It seems to be nearly forgotten that Once Upon a Time, business and scientific computing were more or less different universes.
The two paradigms eventually merged, but there was a problem: it wasn't really a merger. It was more that scientific computing became the implied default, and simply absorbed new and emerging business use cases over time, and actual business computing languished in senescent obscurity.
Scientific computing precepts are dreadful at business use cases (and the reverse is true as well). For an example, one need look no further than the horrors of IEEE 754 in financial calculations, which even Microsoft has admitted are a problem(1).
Now here we are. Every "general purpose" computing architecture and platform out there - from Windows on x86-64 to macOS on aarch64 to Linux on RV64 - is derived from the scientific computing lineage and paradigms.
Small wonder that modernizing and porting decades-old business software is a nightmare.
I know of a place that still uses PL/B, and apparently the language is a hellscape where keywords like "for" or "to" can be redefined on the fly. It sometimes takes a debugger and a copy of the spec to find out what actually happened in a program when it goes south.
It seems to be nearly forgotten that Once Upon a Time, business and scientific computing were more or less different universes.
The two paradigms eventually merged, but there was a problem: it wasn't really a merger. It was more that scientific computing became the implied default, and simply absorbed new and emerging business use cases over time, and actual business computing languished in senescent obscurity.
Scientific computing precepts are dreadful at business use cases (and the reverse is true as well). For an example, one need look no further than the horrors of IEEE 754 in financial calculations, which even Microsoft has admitted are a problem(1).
Now here we are. Every "general purpose" computing architecture and platform out there - from Windows on x86-64 to macOS on aarch64 to Linux on RV64 - is derived from the scientific computing lineage and paradigms.
Small wonder that modernizing and porting decades-old business software is a nightmare.
(1) https://learn.microsoft.com/en-us/troubleshoot/microsoft-365...
Related:
The Eternal Promise: A History of Attempts to Eliminate Programmers (324 points, 3 months ago, 226 comments) https://news.ycombinator.com/item?id=47147597
IBM Plunges After Anthropic's Latest Update Takes on COBOL (113 points, 3 months ago, 106 comments) https://news.ycombinator.com/item?id=47128907
The Code That Controls Your Money (22 points, 2025) https://news.ycombinator.com/item?id=43527332
Doge Plans to Rebuild SSA Codebase in Months (123 points, 2025, 130 comments) https://news.ycombinator.com/item?id=43505659
COBOL has been “dead” for so long, my grandpa wrote about it (425 points, 2024, 437 comments) https://news.ycombinator.com/item?id=41713063
Is relying on a 65 year old programming language much worse than relying on a 54 year old one?
In the case of COBOL vs C, maybe, but not for reasons of age.
This article is a lie. Cobol is still developed and far far from the original lang. It supports ibject oriented programming for example.
Its like C++ - changing and evolving.
It works and its battle tested. 99% people criticizing cobol never actually used it or worked with it
Time to switch to PL/I
I know of a place that still uses PL/B, and apparently the language is a hellscape where keywords like "for" or "to" can be redefined on the fly. It sometimes takes a debugger and a copy of the spec to find out what actually happened in a program when it goes south.
So? If it works it works.
I guess banks don't want to invest in training their people.