10 comments

[ 5.4 ms ] story [ 29.0 ms ] thread
I’ve been experimenting with formal, verifiable modernization and taking a small COBOL batch program and translating it through an intermediate representation and Alloy formal model into Kotlin, while proving equivalence with the legacy output.

Repo: https://github.com/marcoeg/cobol-modernization-playbook

Would love feedback from people who’ve worked on reverse engineering or legacy transformations at scale.

how are you creating the IR?
> formal, verifiable modernization

Would it be possible to do the same to modernize a Kotlin program becoming legacy in the future to something even more modern?

The code is slop, correct?

All the inputs and outputs are hardcoded. The code doesn't do anything except write hardcoded strings to files. Am I mistaken?

Isn't the first code sample pasted in there twice?
The problem I have with all Cobol translation models is that it completely ignores the actual modernization of the system. You've traded one type of syntactic sugar with another.
> 1. Both systems run with the same fixed input files (data/accounts.dat, data/txns.dat).

> 2. Each writes its results to out/accounts_out_*.dat.

> 3. Python scripts convert fixed-width output to CSV and compute SHA-256 checksums.

> 4. If the hashes match — behavior is proven identical.

Step 3 above introduces the possibility that the python scripts alter the output in such a way that the outputs don't actually match prior to the python.

I'm curious why step 3 is not "If the two outputs match — behavior is proven identical."

From the article:

> This enduring reliance exists not out of nostalgia, but necessity: COBOL’s reliability, stability, and the prohibitive cost and risk of replacing decades of deeply integrated logic make it one of the most mission-critical technologies ever built.

That sentence struck me as odd. Is COBOL any more "reliable" or "stable" than any other language? I'm no COBOL expert, but when I've looked at it and read about how it works, it seems rather verbose and mundane. That's not unexpected; it was developed in a different era with different sensibilities.

Having COBOL sources which match whats running in production is a load bearing assumption :).