3 ms·

Not a computer scientist, but surely COBOL could be machine translated to another more modern language - or even a dialect of a modern language specifically cre

Not a computer scientist, but surely COBOL could be machine translated to another more modern language - or even a dialect of a modern language specifically created to make such a translation verifiably correct?

bregma 4y ago
Why? OK, sure, Shakespeare is better when it's been rewritten into modern hip hop rhymes and reinterpreted through lyrical dance but what's the advantage of rewriting something that's working and workable in some other form just because that form is not old?
kryptiskt 4y ago
Sure, there are such translators on the market. The problem is that if you translate COBOL to Java which is the most likely target, you won't end up with any nice OO abstractions but a ton of Java code that looks just like transliterated COBOL.
andylynch 4y ago
There are tools in the market to do this kind of thing, eg to Java. But the typical problem is that you then have a non-idiomatic code base and it’s harder to maintain and operate than the original. So unless it’s an intermediate step on a much larger and more expensive project to replace the whole system it’s too risky for benefit.
Spooky23 4y ago
COBOL was designed for financial analysts, accountants, etc to computerize analog processes. They took it literally sometimes. My favorite example of this was a data entry routine that was insane - and lifted to a web interface circa 2004. “Turns out” when processing paper, several key transactions filtered through a gentleman, long since passed, who lost an arm in Korea. When paperwork was received, they were arranged and stapled in a way that accommodated his mobility limitations. Every COBOL code base has stories like that, and there’s no functions or modern metaphors as it’s procedural. So your opportunities for code translation are really scoped to things that you can make a “black box”, never to be touched again. Remember too this is shitty, unsexy, non-portable work. Top talent started looking elsewhere in the 90s, and often you’re left with a couple of people who understand how stuff works, then mostly folks who value stability over all else. Companies tend to pay for shiny skills, and the folks who really understand their business get second fiddle.
Volker_W 4y ago
If you translate it so that it does exactly the same, the resulting code has a modern language but is even more horrible than the original COBOL code. If you translate it so that is does effectively the same, the resulting code is nice. Unfortunately only the former can be automated. Also, you need to understand the code to do the latter. But reading it is hard and the ones who wrote it are dead/pensioned.
WorldMaker 4y ago
The article even mentions Visual COBOL which is a COBOL compiler to the .NET CLR so you can mix C# and COBOL in the same applications. You can look at the .NET IL disassembly with tools like ILSpy and even get a sense of what the equivalent C# code would look like (and my understanding is that it mostly looks like garbage and nothing like what a good C# library would look like). One perspective on COBOL and why it is such a "write only" language is that it's barely a stone's throw from an Assembly Language with a verbose BASIC-like phrasing. (Well, historically BASIC derives from lessons learned from COBOL rather than the other way around, but from a modern perspective you get the gist.) Every single line has the readability of English, sort of, with that BASIC-like face. Every single line has just about the simplicity of your average basic processor op-codes, just like assembly. To do anything reasonably complex you need lots of lines building up layers of complexity from the simple instructions, just like assembly. Trying to figure out the high level control flow and analyze the overall logic, just like in any disassembly effort, becomes a mind's eye puzzle because there's few ways to visualize the abstractions in the code because the code is at too low of a level for good abstractions. There's no functions and classes, just lots and lots of little instructions. Endless instructions.

bregma 4y ago

Why? OK, sure, Shakespeare is better when it's been rewritten into modern hip hop rhymes and reinterpreted through lyrical dance but what's the advantage of rewriting something that's working and workable in some other form just because that form is not old?

kryptiskt 4y ago

Sure, there are such translators on the market. The problem is that if you translate COBOL to Java which is the most likely target, you won't end up with any nice OO abstractions but a ton of Java code that looks just like transliterated COBOL.

andylynch 4y ago

There are tools in the market to do this kind of thing, eg to Java. But the typical problem is that you then have a non-idiomatic code base and it’s harder to maintain and operate than the original. So unless it’s an intermediate step on a much larger and more expensive project to replace the whole system it’s too risky for benefit.

Spooky23 4y ago

COBOL was designed for financial analysts, accountants, etc to computerize analog processes. They took it literally sometimes. My favorite example of this was a data entry routine that was insane - and lifted to a web interface circa 2004. “Turns out” when processing paper, several key transactions filtered through a gentleman, long since passed, who lost an arm in Korea. When paperwork was received, they were arranged and stapled in a way that accommodated his mobility limitations. Every COBOL code base has stories like that, and there’s no functions or modern metaphors as it’s procedural. So your opportunities for code translation are really scoped to things that you can make a “black box”, never to be touched again. Remember too this is shitty, unsexy, non-portable work. Top talent started looking elsewhere in the 90s, and often you’re left with a couple of people who understand how stuff works, then mostly folks who value stability over all else. Companies tend to pay for shiny skills, and the folks who really understand their business get second fiddle.

Volker_W 4y ago

If you translate it so that it does exactly the same, the resulting code has a modern language but is even more horrible than the original COBOL code. If you translate it so that is does effectively the same, the resulting code is nice. Unfortunately only the former can be automated. Also, you need to understand the code to do the latter. But reading it is hard and the ones who wrote it are dead/pensioned.

WorldMaker 4y ago

The article even mentions Visual COBOL which is a COBOL compiler to the .NET CLR so you can mix C# and COBOL in the same applications. You can look at the .NET IL disassembly with tools like ILSpy and even get a sense of what the equivalent C# code would look like (and my understanding is that it mostly looks like garbage and nothing like what a good C# library would look like). One perspective on COBOL and why it is such a "write only" language is that it's barely a stone's throw from an Assembly Language with a verbose BASIC-like phrasing. (Well, historically BASIC derives from lessons learned from COBOL rather than the other way around, but from a modern perspective you get the gist.) Every single line has the readability of English, sort of, with that BASIC-like face. Every single line has just about the simplicity of your average basic processor op-codes, just like assembly. To do anything reasonably complex you need lots of lines building up layers of complexity from the simple instructions, just like assembly. Trying to figure out the high level control flow and analyze the overall logic, just like in any disassembly effort, becomes a mind's eye puzzle because there's few ways to visualize the abstractions in the code because the code is at too low of a level for good abstractions. There's no functions and classes, just lots and lots of little instructions. Endless instructions.