Comment by amelius
5 years ago
How hard would it be to automatically convert that COBOL to e.g. C++ or Rust? I suspect not that hard, since COBOL does not even have a heap afaik.
5 years ago
How hard would it be to automatically convert that COBOL to e.g. C++ or Rust? I suspect not that hard, since COBOL does not even have a heap afaik.
Presumably, hard:
https://aws.amazon.com/blogs/apn/automated-refactoring-of-a-...
And then you have a bunch of code that's even harder to understand than the original, working in ways you don't expect from the language it's now in.
And not working with the normal build or debug tools on the mainframe it runs on.
A high-fidelity translation between almost any two serious programming languages sound like a very difficult task. The first 95% might indeed be quite easy, but the last 0.1% would often turn out to be extremely difficult. And if the software "matters", you have to achieve 100%.
It can be automatically translated. But then all you've done is convert a bunch of IF A < B THEN GO TO STEPTWO into if (a < b) { goto steptwo; }
And with a lot of extra unreadable stuff to support things COBOL does but the target language doesn't.
The biggest problem with COBOL codebases is that COBOL (at least back in the day) doesn't offer much in the way of structured programming or standard libraries. Horrifying spaghetti code with one-off local solutions for common tasks is the norm, especially on some ancient endlessly patched code.
Not true, COBOL has as much structure as any other language, if the programmers wrote their code that way.
The main problem with a direct conversion is COBOL has database operations in the language, mapping data directly to variables (records). All modern languages you might translate COBOL to use libraries to perform database operations, and may not even have an off-the-shelf implementation of the pre-relational data structures COBOL was originally designed to work with.
The ignorance of cobol is not the blocking point.
Ignorance of the details of the NJ system is the great challenge. Its likely a huge legacy system with all of the attendant warts, histories, strange choices, and odd limitations that come with that. Given that these systems are built up through years of teams of people that come and go - it will likely take a long time to address the real issues.
> The ignorance of cobol is not the blocking point.
> Ignorance of the details of the NJ system is the great challenge.
This seems very plausible. But on this analysis, what's the point of trying to hire "COBOL programmers"? We've just stipulated that the COBOL is easy. Onboarding an experienced COBOL programmer is only a trivial savings over onboarding someone who's never heard of COBOL; they'll both have to learn the system -- but the pool of experienced COBOL programmers is much smaller than the pool of "everyone".
I don't disagree - but its a government agency and so the job requirements are always going to come out like that. Between that and the below market pay - there is a long road ahead for them.
From what I gather, it's an issue of floating point precision. See more here: https://medium.com/@bellmar/is-cobol-holding-you-hostage-wit....
Lots of things don't have a 1:1 match. For example Cobol has a PICTURE clause for describing a record. It uses 1 character symbols like in fscanf() but there are different options. Like binary coded decimal.