81–90 of 448 posts
COBOL is dead, long live COBOL. For any cobol devs here, we at https://cobolcopilot.com would love to hear from you
Bloomberg's Odd Lots podcast had an episode last year, "This Is What Happens When Governments Build Software": * https://www.youtube.com/watch?v=nMtOv6DFn1U One reason COBOL systems have been around for so long is because they encoded business rules that need to be understood if you want to try to transfer them to a new system. From the podcast (~16m): > Like when we're working in unemployment insurance, again during…
There is not permission to say that because your requirements are often set in a black letter law and you didn't buy a right kind of suite to be present where they were decided for the last 40 years.
"I don't know what the language of the year 2000 will look like, but I know it will be called Fortran." —Tony Hoare COBOL is alive in that it keeps changing from era to era, to the point modern COBOL looks rather little like the 1950s COBOL everyone instinctively thinks about when they heard the term. It's as if we were still programming in Algol because Java had been called Algol-94 or something.
Earlier quoted context omitted.
About a decade ago I looked into moving some COBOL components off-mainframe (either as COBOL-on-Linux or a rewrite into Java, which itself is really COBOL Mk II at this point), and your point about the operating environment is one of the key elements, but not all of it; there's also the fact that the first big shift to automation, via mainframe assembler and COBOL, is when companies sacked a lot of the folks who knew…
> A rewrite or a replatform is very, very hard and risky as a result; the system is now defined by how the mainframe runs the processes, to a very large degree. And that's why so many neo-banks/fintechs are eating the lunch of the established banks left and right, same for insurance. The "old guard" is unwilling to pay the costs of not just upgrading off of mainframes (aka the rewrite work itself)... but of changing…
Source: worked there for many years, and built some of those integration systems.
You know, one of these days I really need to sit down and play with some of these "legacy" languages, like Fortran or COBOL or Ada or APL; languages that have certainly fallen out of popularity but are still used in some critical places. It does make me wonder about millions and millions of lines of Java out there; Java has more or less eaten the enterprise space (for better or worse), but is there any reason to thin…
I expect Ada will capture 0.05% of the market for the next 100 years.
Earlier quoted context omitted.
Shell script is memory safe too, but you don't write anything longer than 100 lines in it for a reason.
When you bank, COBOL (40% of online banks). When you use the ATM, COBOL (95% of ATM transactions). When you travel, COBOL (96% of airline ticket bookings). Healthcare, COBOL. Social Security, COBOL. Point of Sale, COBOL. IRS, COBOL. Pension funds? COBOL. Hotel bookings? COBOL. Payroll programs? COBOL. It is estimated that there is 800 billion lines of COBOL code in production systems in daily use. That is a bit more…
It's just that nobody understands how the systems work and they're ossified. Those systems are going to be emulated until our grandchildren take over because nobody can understand them well enough to craft a replacement. Juuuust up until an LLM rewrites them for us.
[edit] I mean those airlines systems are so old that they don't support special characters on names, passenger names are two fixed-length fields (first name, last name) and title and middle name just gets appended together.
So you get LASTNAME/FIRSTNAMEMIDDLENAMENTITLE on your bookings. And each of those fields is truncated lol.
and of course flight numbers are fixed at 4 digits, so we're running out of those.
Not exactly a great ad.
Earlier quoted context omitted.
When you bank, COBOL (40% of online banks). When you use the ATM, COBOL (95% of ATM transactions). When you travel, COBOL (96% of airline ticket bookings). Healthcare, COBOL. Social Security, COBOL. Point of Sale, COBOL. IRS, COBOL. Pension funds? COBOL. Hotel bookings? COBOL. Payroll programs? COBOL. It is estimated that there is 800 billion lines of COBOL code in production systems in daily use. That is a bit more…
Legacy code yeah, nobody's hitting File > New Project in COBOL It's just that nobody understands how the systems work and they're ossified. Those systems are going to be emulated until our grandchildren take over because nobody can understand them well enough to craft a replacement. Juuuust up until an LLM rewrites them for us. [edit] I mean those airlines systems are so old that they don't support special characters…
Yeah, there are fewer engineers in COBOL which is why it pays BIG bucks now. They desperately need someone to maintain that massive infrastructure that has been built up over 75 years that cannot be replaced easily or quickly.
Bloomberg's Odd Lots podcast had an episode last year, "This Is What Happens When Governments Build Software": * https://www.youtube.com/watch?v=nMtOv6DFn1U One reason COBOL systems have been around for so long is because they encoded business rules that need to be understood if you want to try to transfer them to a new system. From the podcast (~16m): > Like when we're working in unemployment insurance, again during…
> ...add edge cases as as later.” There's no permission really to say that. I think there would be some value to closing that feedback loop to give legislators the signal "You know, what you're considering is actually pretty fuzzy conceptually... We're discovering while considering how to code it up that you probably don't actually have good, clear definitions for all the terms in this bill." But the biggest thing to…
That's all very true, but nobody ever codifies that. When the data doesn't fit the constrains of the form that aims to handle a reasonable generalilized case, you simply get a phone call from a human in the loop. That human has a supervisor and you can also go to a court when they write your name with E instead of É and try to bullshit you about some kind of ASCIEBCDIC nonsense like it's real.
In the end you have one dataset which tells who is a child of who, another telling who has custody rights and a third one making sense of amounts and recipients of childcase subsidies. Maintained by different departments and eventually consistent or maybe not.
Earlier quoted context omitted.
Can't we just apply a bunch of correctness preserving translations towards a modern PL, perhaps aided by an LLM to keep the source as human readable as possible, while (I'm stressing this) preserving correctness?
IBM offers just such a service under the WatsonX branding, it's an LLM to convert COBOL to Java: https://www.ibm.com/products/watsonx-code-assistant-z I work at a company with a large COBOL codebase and this has been mentioned in a few presentations about our modernization efforts.