I did COBOL for two years out of college. It is the most frustrating and terrible language to work in. We weren't using it on a mainframe we were using it to build GUI apps that run on client machines. I would spend days writing code that would take 20 minutes in c#.There were 10k line files with all global variables and you might think it was just bad design and what not but the team was very disciplined and focused on quality. There are no tests, documentation or Google queries to help you. Your job is to dig in an enormous codebase to understand what it does and that is tough. The developer output compared to a modern language is tiny compared to a Java or .NET developer.
I know it isn't cool, but I often wonder if anyone will come out with a language that isn't meant to be the next C but the next COBOL, RPG, etc. I wonder if anyone has a LLVM backend for z/Architecture and TIMI.
That’s a problem I’ve occasionally considered working on—modern alternatives with tractable, incremental migration paths away from COBOL/RPG/MUMPS—but I hardly know where to begin.
I’m sure for a lot of these companies, due to the sheer size and often mission-critical nature of these systems, the cost analysis still comes down on the side of keeping the COBOL/&c. systems and just using new tooling around them, like static analysers, integrations with frontend frameworks, ways to interoperate with relational databases, and software emulation of mainframes.
An alternative would be not only difficult to build but hard to sell. There’d probably be a lot of money in it if you had
a team with the financial runway, technical skills, and market connections to do it, though.
I've thought about it a bit, and I do wonder if defining a VM and compiling the COBOL/RPG/MUMPS to it first then building the language off that. The languages are pretty straight forward and defining a decent high level VM instruction set would probably help with the not only the conversion but provide some assurance that you didn't miss something important.
There is documentation for the MI instructions, but that generates an OPM program and not an ILE program on IBM i. Sadly the TIMI isn't really documented anywhere - as well as ILE.
I have written an RPG3 interpreter with all the Record Level Access operations working on a noDb/flatfile in C#, but lost the source after replacing a hard disk. I have also tried writing a RPG4+ (only free format) compiler for .NET, but it started getting tricky when starting to write the RLA operations because they relied on a database. I have the code still, but it's ugly so I never released it.
Would be a fun project, for sure. Not enough hours in the day.
