I guess not even IBM stands COBOL anymore. Maintaining those tools ad-infinitum is cost that IBM is not happy about (as much as it might be "lucrative" but it is trying to swim on honey)
And to be honest, COBOL is so verbose that most complexity is hidden but it is overstated (I mean, the libraries/APIs are awkward because of COBOL - you need to pick the complexity at the right level to convert)
You make it sound as though the LLM they created is ready to take over. Fixed. Done!
Off course COBOL's code base is valuable because it works, and expensive because no one dares making changes, please don't fix it unless it's broken. In that climate the dollars are mostly spent on paperwork, much less on the programmer that knows COBOL and even less on COBOL's verbosity.
Rather than wasting money on COBOL, I guess IBM will be wasting money babysitting an LLM that does COBOL that even less people are trained to understand (or care to). :-)
> COBOL's code base is valuable because it works, and expensive because no one dares making changes, please don't fix it unless it's broken
That's not always possible. Both on the customer's side (mandatory changes, bug fixes, etc) and IBM's side (OS/machine updates, support of the associated tooling, etc)
If Banks, etc are having trouble hiring people to fix COBOL, how hard do you think it is to find someone that can fix or extend a COBOL compiler?
Not to mention under the hood is like a car that runs on a steam engine.
> as though the LLM they created is ready to take over
I neither said nor believe in this, translating code is one part of the problem
What I'm trying to say is that with COBOL, the hard part is stasis and the reason isn't COBOL, but the legacy context in which COBOL is still present.
For years, software has been migrated away from COBOL. Starting afresh, re-implementing, manual translation, transpiling. What remains, is there because it works and no one want to touch it.
If there would exist a reliable, risk free migration path to generate Java code, I'm sure that is not the situation we're talking about. There are always risks and that's where the paperwork comes in.
I've done my share of porting Pascal to C or transpiling 4D into C++. Lua to Python.
Given the right tools, it is usually not the tedious translation task but the lack of automated tests, foreign function interface calls, archaic hardware quirks, event orders and real-time constraints that are causing the issues.
Not sure and LLM is very helpful here. Even if it's incredibly clever in producing Java from COBOL 99% of the time, the paperwork is only about the 1% of errors it may introduce. Absent a formal, exhaustive validation of the LLMs's capabilities its contribution basically comes down to a huge code review for a pull request of unknown origin.
I guess not even IBM stands COBOL anymore. Maintaining those tools ad-infinitum is cost that IBM is not happy about (as much as it might be "lucrative" but it is trying to swim on honey)
And to be honest, COBOL is so verbose that most complexity is hidden but it is overstated (I mean, the libraries/APIs are awkward because of COBOL - you need to pick the complexity at the right level to convert)