Mainframes aren’t some old crusty thing that’s about to die from all the bugs stuck in the fans or something. We have a cobol system and it runs on modern IBM hardware. Besides, almost everything is virtualized now anyway.

The mainframes aren’t the problem, and doing a code conversion of COBOL is not trivial. Their data types are completely at odds to normal data types in modern languages (for example, you can specify a string that is always exactly 30 ascii characters long, the 4th character must be a numeric, the 18th must be ascii but not numeric, the 22nd through 30th must be alphanumeric. All with a native datatype. And that’s just the scalar types, Cobol data types natively support recurrences and redefines and heirarchies. And the language has like 400 keywords.) You end up having to wrap every single line of code in compatibility layers upon compatibility layers, and then it doesn’t even look like python, it just looks like a crappier version of Cobol, to make it function identically.

It’s much easier (though more time consuming) to read the code and determine the business rules being enforced and reimplement them in a modern language.

I have worked with a lot of Cobol translators and their output is worse than the original code by far. With a lot less confidence and experience with maintaining it.

Given that the Python foundation has been trying to get folks to run a python-to-python converter for more than a decade and have not completely succeeded, I'm skeptical that an AST transformer is really sufficient for migrating off those legacy systems.

More constructively, having worked on a (close to decade-long, by the time I joined) project to migrate a financial institution's business logic off an IBM mainframe onto more modern architecture, my main takeaway was that these systems have worked pretty darn well for decades with relatively little maintenance. The reluctance of companies to migrate god-knows-how-much data, business rules, and institutional knowledge (e.g. of data entry folks, business-level administrators who have to navigate these systems to do their job, etc) off a time-tested system they trust at massive expense, is completely understandable.

This is a misunderstanding of the problem. It’s not the fact that it’s COBOL, per se, that’s the problem. The issue is with making changes to an entire system. A program written in COBOL may be at the center of that system, but that program is only one part of it.

I don't know if it's still true, but COBOL systems were really well optimized for I/O, for performance, etc. Python won't stand a chance...