I've been translating between c# and python and having a great deal of success at the function and class level. I even ported unit tests easily between xunit and pythons unittest library. I've got close to 100% test coverage so I'm fairly confident it's done well
translating a 20yo project written in a language that isn't used much anymore is a lot different
The code looks good, and that's a great success. What else would you like?
Essentially, you want to build an artificial programmer ("junior dev") who can work with a better developer/manager. That seems to be the way in the short-term. Doing this by just single-shot text transformation is a lot harder. Humans can't really do that neither.
In particular the way that object destruction works is completely different. VB6 using reference counting and .Net languages use a garbage collector.
Systems using reference counting destroy objects and run the destructors as soon as there are no references to the object while those using garbage collectors might only dispose of the objects when memory is low, perhaps never. This means that object lifetime can be very different and that patterns such as RAII require extra work in .Net.
What exactly is more modern about a system that does not have deterministic finalization as part of object scope?
I tried asking ChatGPT to do it. It looked good on the surface, but it had subtly mangled some of the if conditions, etc, which resulted in it producing completely different numbers from what the original Fortran code did.
Then I remembered good old f2c, and I tried using that. Unlike ChatGPT, the code f2c produced was (as far as I can tell) correct, albeit a lot uglier. But it is a lot easier to refactor ugly-but-correct code into nicer-and-correct code, than incorrect code into correct code.
Having done a year-long stint at a mainframe team in one of the large financial corps (no, bigger than that) I can assure you that this is never going to happen for COBOL-to-java (or to-anything) unless there are strong guarantees of 100% correctness. See, one of the first things they tell you when you join a COBOL team is that you don't touch the code, unless you've filed a form that explains every detail of the change you want to make and why. In the team I worked for, that was a 10+ page Word form that would put a herd of elephants to sleep with its obstinacy and recalcitrance.
And that was only to change some JCL scripts- the scripts that run the COBOL jobs. Nobody dares to change now 50-years old COBOL code. Because every time they do, the corp loses millions. So I was told by those who knew better than me, and had been doing that job all their lives.
Bottom line, until someone figures out how to transform a gigantic, half a century-old COBOL codebase into java without breaking nothing at all, there's not gon' be any migrations.
I get a feeling that the requirements for scientific code are going to be much looser, and that this is going to cause a whole lot of mayhem, on the other hand.
I tried to migrate a twenty year old Visual Basic 6.0 project to c# by doing it piecemeal with GPT4 and it failed completely. Both in the UI and the backend. I am keeping my fingers crossed for a GPT n+1 that actually can do this.
Incidentally, I found out that GPT4 (as in chatGPT) is very useful if you need to program in VB6 which is nearly absent from search results these days.