>> This would really useful if it worked with legacy code. For example, you could migrate all that COBOL code into Java or Python, or all the Fortran scientific

>> This would really useful if it worked with legacy code. For example, you could migrate all that COBOL code into Java or Python, or all the Fortran scientific code into C++ or Python. 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.