4 ms·

There's something very true about that. COBOL knowledge is quite literally dying out. However, for the most part those systems have been running for decades an

There's something very true about that. COBOL knowledge is quite literally dying out. However, for the most part those systems have been running for decades and aren't modified that much any more. While probably not completely bug-free they tend to have a low error rate, in terms of functional requirements at least. They also mostly deal with low-level mathematical and accounting functions that don't change frequently. For better or worse a lot of COBOL code also gets replaced when new compliance measures like Basel II and III are implemented. Additionally, there are even transpiler-like tools that convert COBOL to Java code. The resulting code of course is horrible but at least it then is available in a language with a long-term maintenance outlook. In addition to a very conservative work environment all of this contributes to COBOL not having the prospects it might seem to have at face value.

shakna 9y ago
> For better or worse a lot of COBOL code also gets replaced when new compliance measures like Basel II and III are implemented. That's really not my experience. I was brought in to maintain, and manage a series of changes to a major bank in Australia, where I trained a full-time replacement before leaving. We replaced COBOL code... With more COBOL. > Additionally, there are even transpiler-like tools that convert COBOL to Java code. The resulting code of course is horrible but at least it then is available in a language with a long-term maintenance outlook. Not just horrible to look at. Slow. Performance that is hundreds to thousands of times slower than the pre-existing code. That's just not acceptable. --- Now, we were writing "new" stuff in a different language - C++, because IBM has a wonderful linker framework between Fortran and C++ on their mainframes. But the COBOL is staying put, because nothing can really replace it without unacceptable downtime or performance regressions.

shakna 9y ago

> For better or worse a lot of COBOL code also gets replaced when new compliance measures like Basel II and III are implemented. That's really not my experience. I was brought in to maintain, and manage a series of changes to a major bank in Australia, where I trained a full-time replacement before leaving. We replaced COBOL code... With more COBOL. > Additionally, there are even transpiler-like tools that convert COBOL to Java code. The resulting code of course is horrible but at least it then is available in a language with a long-term maintenance outlook. Not just horrible to look at. Slow. Performance that is hundreds to thousands of times slower than the pre-existing code. That's just not acceptable. --- Now, we were writing "new" stuff in a different language - C++, because IBM has a wonderful linker framework between Fortran and C++ on their mainframes. But the COBOL is staying put, because nothing can really replace it without unacceptable downtime or performance regressions.