4 ms·

> What do we do? Keep rewriting everything every 50 years? Uh… sure? What would you consider an acceptable minimum amount of time to be after which rewriting a

> What do we do? Keep rewriting everything every 50 years? Uh… sure? What would you consider an acceptable minimum amount of time to be after which rewriting a large but fairly critical codebase to modern standards becomes acceptable? > And those ancient Cobol codebases actually have a big advantage: they've been maintained for so long that all the major bugs have been virtually eliminated. Creating a new system from scratch means another 10 to 20 years of maintance until the new system reaches the stability of the old one. That's not quite fair. Having a known good code base while porting means that you can just rewrite the existing algorithms in the new language and then run some automated tests to make sure you get the same output from the same input across both systems. Unless you're doing a black-box rewrite for some reason, you're not really throwing away all fo the maintenance done on the existing system.

YeGoblynQueenne 7y ago
Unfortunately, nothing works that effortlessly in software. Re-writing an existing algorithm is one thing, but even that is likely to be a big source of new bugs, given that Cobol is actually a quite low-level language and much code will rely on its specific view of a mainframe's architecture. The bigger problem is that any implementation of complex business logic is going to depend very heavily on the facilities provided by whatever language it's originally implemented in (Cobol, in this case, obviously). A direct translation to a new language is likely to be completely impossible. And the bugs will grow in all the semantic gaps between the old language, and the new. And that's before considering that, for Cobol in particular, the Cobol code itself is only half the story. Cobol programs run as batch jobs controlled by JCL ("Job Control Language") which often means that crucial aspects of businees logic are spread over multiple files in _two_ languages. And the JCL part is a mess. I didn't mind Cobol when I was working with it, I even came to like it a bit actually. JCL is really, really awful. But, aesthetics aside, where does all the JCL-encoded logic go? Is that translated to the new language, also? That's going to be really hard given that JCL is operating-system specific. Is it going to be translated in scripts in a new shell language? The difference between concepts on JCL and, say, bash, or powershel, is going to be impossible to bridge without making drastic changes- and cultivating new bugs. In general, translation of a large codebase between two very different languages is going to cause lots and lots of new bugs. So, if you rewrite everything every 50 years, in 200 years you'll spend a total of 40-80 years fixing bugs. If you write it once and let it be, you'll spend at most 20. I don't see a good reason to do it. And what's wrong with an "antiquated language" anyway? I mean is it just aesthetics we're talking about here? Is it the lack of programmers that's the problem? The latter is sure to make translation even harder and more bug-prone. What is the real reason to change a working codebase every n years?

YeGoblynQueenne 7y ago

Unfortunately, nothing works that effortlessly in software. Re-writing an existing algorithm is one thing, but even that is likely to be a big source of new bugs, given that Cobol is actually a quite low-level language and much code will rely on its specific view of a mainframe's architecture. The bigger problem is that any implementation of complex business logic is going to depend very heavily on the facilities provided by whatever language it's originally implemented in (Cobol, in this case, obviously). A direct translation to a new language is likely to be completely impossible. And the bugs will grow in all the semantic gaps between the old language, and the new. And that's before considering that, for Cobol in particular, the Cobol code itself is only half the story. Cobol programs run as batch jobs controlled by JCL ("Job Control Language") which often means that crucial aspects of businees logic are spread over multiple files in _two_ languages. And the JCL part is a mess. I didn't mind Cobol when I was working with it, I even came to like it a bit actually. JCL is really, really awful. But, aesthetics aside, where does all the JCL-encoded logic go? Is that translated to the new language, also? That's going to be really hard given that JCL is operating-system specific. Is it going to be translated in scripts in a new shell language? The difference between concepts on JCL and, say, bash, or powershel, is going to be impossible to bridge without making drastic changes- and cultivating new bugs. In general, translation of a large codebase between two very different languages is going to cause lots and lots of new bugs. So, if you rewrite everything every 50 years, in 200 years you'll spend a total of 40-80 years fixing bugs. If you write it once and let it be, you'll spend at most 20. I don't see a good reason to do it. And what's wrong with an "antiquated language" anyway? I mean is it just aesthetics we're talking about here? Is it the lack of programmers that's the problem? The latter is sure to make translation even harder and more bug-prone. What is the real reason to change a working codebase every n years?