This idea of using #AI to translate #COBOL code into #Java has one big problem.
The goal is reasonable: ancient COBOL code is effectively a black box, hard to modify or extend and even harder to debug.
But who is validating the Java output? A big part of the problem is how difficult it is to understand the business logic that the COBOL was implementing — but all that analysis work is still required to evaluate the correctness of the Java, plus Java debugging!
https://techcrunch.com/2023/08/22/ibm-taps-ai-to-translate-cobol-code-to-java/
@riotnrrd ... We could have a discussion about your opinion of COBOL. Your second point is on target. Developers responsibly write and test COBOL to Java translators and carefully make sure the results are correct (#heirloomcomputing among others). AI is a different matter altogether. GnuCOBOL simply compiles it to C and uses gcc to produce native programs. Our COBOL for GCC (gcobol) will be a GCC - native compiler. Recompilation is often all that is needed.
@Marty Oh, I did not mean to denigrate COBOL! While I have never written any, I know enough to understand at least the high points of why it’s still around. It’s the conversion by LLM that is the problem. If I’m the owner of a business process, and I’m presented with a bunch of Java code extruded by an LLM, I have no way of validating that output, whether against the original COBOL or against my actual requirements. At least if it’s written by humans, we can talk through it.
@riotnrrd By the way, LLVM being one thing, GCC another, COBOL for GCC is being submitted to GCC for 15 right now. Incomplete but the core language is there.