3 ms·

So it sounds like COBOL really isn't the problem. Its that is 10M lines of complicated probably poorly written (in terms of hard to understand and little comme

So it sounds like COBOL really isn't the problem. Its that is 10M lines of complicated probably poorly written (in terms of hard to understand and little comments and no test coverage) code. Otherwise companies successfully transpile far bigger code bases than 10M lines... IMO the first thing they should be doing is writing automated tests against the existing COBOL. A transpiler might help this process.

marktangotango 9y ago
You are absolutely right, that's the nuance that's often missed in these discussions. The COBOL applications in question grew organically over decades to encompass business processes for entire industries. There was never a single design document or even goal. The other thing is how these systems were architected. They were mostly all green screen apps that build data files that were then fed into extensive (complex, large) nightly batch processes. For example today when you do a transfer between bank accounts, you may expect the transfer to be immediate. most often it's shown in a pending status until after the next nightly process. This is why.
- marktangotango 9y ago
  Edit: further, the problem with transpiling is that these systems are still under active development. For example, banking systems have to be updated annually for changes in regulations and tax laws. If you translated all you COBOL to Java (which results in truly inscrutable code (cobol has unusual control flow constructs, even besides go to)). Then as an organization you're face with either modifying the Java code (this is very, very, very bad), or regenerating from COBOL periodically, which kind of defeats the purpose.
- collyw 9y ago
  I always assumed it was so the banks could skim off the interest generated for another night.
- woah 9y ago
  Are there any good resources on the architecture of these systems? It sounds very different from the application and web programming that I know and it would be interesting to learn about it.
fiftyacorn 9y ago
In my experience these systems are not poorly written - the process around these systems is huge, with reviews and reviews, and lots of testing

marktangotango 9y ago

You are absolutely right, that's the nuance that's often missed in these discussions. The COBOL applications in question grew organically over decades to encompass business processes for entire industries. There was never a single design document or even goal. The other thing is how these systems were architected. They were mostly all green screen apps that build data files that were then fed into extensive (complex, large) nightly batch processes. For example today when you do a transfer between bank accounts, you may expect the transfer to be immediate. most often it's shown in a pending status until after the next nightly process. This is why.

marktangotango 9y ago
Edit: further, the problem with transpiling is that these systems are still under active development. For example, banking systems have to be updated annually for changes in regulations and tax laws. If you translated all you COBOL to Java (which results in truly inscrutable code (cobol has unusual control flow constructs, even besides go to)). Then as an organization you're face with either modifying the Java code (this is very, very, very bad), or regenerating from COBOL periodically, which kind of defeats the purpose.
collyw 9y ago
I always assumed it was so the banks could skim off the interest generated for another night.
woah 9y ago
Are there any good resources on the architecture of these systems? It sounds very different from the application and web programming that I know and it would be interesting to learn about it.

fiftyacorn 9y ago

In my experience these systems are not poorly written - the process around these systems is huge, with reviews and reviews, and lots of testing