There are plenty of ways to port out of COBOL, none will work.<p>I once interviewed for a COBOL position. It was a typical large financial institution. It was a lead position that wanted a migration plan out and then would lead to a team for me. I have a lot of systems integration and information management knowledge. I have worked on planning multi-year projects and migrating out of large systems like this before.
The interview went well, and afterwards they showed me around the place and what they were doing.<p>I sat down again in the office with the hiring director, and I enquired about how long he has been with the company and what he has been working on. Turns out he had been hired in five years ago and had already attempted this once before without success. I knew without a doubt why they didn't have success, and it had nothing to do with COBOL.<p>Financial companies are highly risk adverse. COBOL developers know this. COBOL developers know that if the shop isn't COBOL their job is at risk. So, COBOL developers will constantly introduce "what about this risk" issues, which then must be considered in committee; thus, the company is eternally paralyzed. The fact that the director couldn't make it anywhere in five years meant nothing was going to change.<p>As I recall, I checked in a few years later and they were still in the same place. I suspect it might have been a decent place if all I wanted in life was a paycheck. They were nice people.
> What if we could transpile COBOL into Elixir<p>You've then successfully ported your code base from one language for which it's really difficult to find programmers to another language for which it's really difficult to to find programmers.
You can transpile anything to anything, but computers will not be able to rewrite the code to match idiomatic style in the new language. Rather, (taking the example from the article) you get COBOL style in Elixir syntax and everyone is unhappy. Much better options are to maintain a COBOL team that continuously updates the program during its lifetime so that knowledge of how it works is never lost, or (if that is no longer possible) do periodic rewrites every two decades or so.<p>If your first response to this is "but that would cost a fortune!", you are completely correct. The biggest illusion in software is that a "complete" program is now "done" and will need no more investment. Software is a machine for producing information, fundamentally not much different from a lathe or a textile loom. If your company depends on a piece of software to continue existing, it is now de facto a software company. Many institutions have not yet realized this and will run into existential problems within a few decades.
The issue typically isn't just the COBOL itself, but the surrounding architecture. This will take in the nuances of the underlying operating system, system language operations and batch tasks.<p>For example, the COBOL might potentially have been on an ICL VME system. This will undoubtedly have a lot of support code written in things like SCL (System Control Language), and potentially even 68k assembly.<p>There are companies which specialise in migrating COBOL code from legacy environments. This can involve migrating the COBOL code itself to a different variant and rigorously testing it, and then often introducing utilities which replace operating system functionality which was present on the original mainframe.<p>The alternative is to "salami slice" bits of functionality into modern services written afresh, and slowly work towards decommissioning the old setup, but often this has to be done at the same time as a migration to modern hardware, due to the scale of the systems involved and the time taken for these sorts of projects to complete.
I feel a need to comment but I can't find a form of words that isn't condescending to the point of rudeness. So this will probably come off as rude...<p>Transpiling, to more or less any language, is the easy bit. By a very, very long way. The hard bit is everything else. I mean, do they really think they're the first people to think about using a transpiler over the last 30/40/50 years?<p>If they had said that they'd used their transpiler on a real production codebase and their transpiled code <i>was now running in production in any volume</i>, I'd be quite impressed. But they didn't say that because it's blatantly obvious from the tone of the article that that will never occur.<p>Now, I don't have any issue with people being ignorant of a subject that they don't understand. That's the norm for most people for most things. But I have to say that this level of naivety doesn't reflect well on their company. They clearly made no effort to understand the problem that they are purporting to solve. Is that really how they function as a company?
The Japanese have a philosophy whereby they will rebuild a shrine every 20 years. The knowledge of what is necessary remains current, and understood. And the shrine continues in its purpose.<p>Perhaps we should consider how we can regularly rewrite different parts of our software ecosystems using new languages and approaches while preserving the essential knowledge and security aspects of what we have already built?<p>The important part isn't the language that the code is written in, it is the full understanding of the problem and thus the solution provided.
You will have solved the easiest part. Now get started on replicating JCL, VSAM, CICS, IMS, RACF, and the rest of the ecosystem that COBOL code depends on :)
Please no...<p>I've been unfortunate enough to witness first hand what +-5,0000,000 lines of Natural Adabas code transpiled to +-15,000,000 lines of Java code looks like, and it was not pretty.
I checked my bookmarks, and there have been success stories for porting cobol into other languages. Here's a discussion from 2019, from cobol into Java: <a href="https://news.ycombinator.com/item?id=19839563" rel="nofollow">https://news.ycombinator.com/item?id=19839563</a><p>Phase 1: automation of cobol to (ugly) Java<p>Phase 2: make the code more idiomatic for (cleaner) Java<p>Phase 3: move the infrastructure to AWS<p>In the discussion, someone mentioned "There are commercial COBOL compilers available that compile to Java bytecode."<p>Offhand, if someone were still on cobol, I'm not sure if they'd trust the comparatively new Elixir, but I can also see leapfrogging being a thing. (And I know it's based on Erlang, which pre-dates Java.)
This reminded me of the old lisp2cobol[0] joke script.<p>[0] <a href="https://stuff.mit.edu/afs/sipb.mit.edu/project/lisp2cobol/l2c" rel="nofollow">https://stuff.mit.edu/afs/sipb.mit.edu/project/lisp2cobol/l2...</a>
No one running COBOL will use it because those legacy applications "just work". Debugging and making certain the resulted transpiled code does as well will take a monumental effort (read: money). That is why those codebases haven't been ported because, based on similar efforts, transpilers are only partially easier than a manual rewrite.<p>That answering the what if question. The project itself is interesting.
Why should we? When we have this: <a href="http://www.coboloncogs.org" rel="nofollow">http://www.coboloncogs.org</a><p>Sorry, no https availlable.
Anybody who is developing a COBOL compiler should know that there's a test suite for the language. See here (<a href="https://www.itl.nist.gov/div897/ctg/cobol_form.htm" rel="nofollow">https://www.itl.nist.gov/div897/ctg/cobol_form.htm</a>)<p>Also, I haven't seen any mention of any of the bits of the COBOL ecosystem here? No DB2, IDMS, IMS DB/DC, VSAM, CICS, REXX, JCL? These are a big part of why COBOL applications are sticky.
COBOL code is surprisingly readable when compared to "modern" JavaScript-like languages. The site linked above shows a very good example of this.