6 ms·

I don't want to sound condescending but why can't these systems be rewritten in a modern language? Now is obviously not the right time to do this; I am wonderin

I don't want to sound condescending but why can't these systems be rewritten in a modern language? Now is obviously not the right time to do this; I am wondering are there technical limitations to do his?

jimbob45 7y ago
They’d have to be revalidated. Don’t fix it if it’s not broken. Edit: and when do you upgrade? If they upgraded in ‘85, it would be in C++. ‘95, and it would be Java 1.0. ‘05 and it would have been VB6. None of those would have been substantially better save that they would have been easier to hire maintenance programmers for.
- luckylion 7y ago
  And now that they're broken, they can't be fixed. ;) With so many legacy systems that are often in very important places, I wonder whether it wouldn't be smarter to spend money on systems converting a modern language to cobol, e.g. python2cobol. Is that impossible?
  - number6 7y ago
    I guess there are technical reasons. a big bank does risk assessment. I can't imagine a problem like this will go unnoticed for long
- number6 7y ago
  Ok got it. But it seems to be broken somehow if they need programmers now. Maybe write the tests first so it can be validated easier?
- ghayes 7y ago
  C++ or Java seem like great alternatives. And I don't get the reference to VB6-- in 2005, it would still have been Java, and in 2015.
- bluedino 7y ago
  Upgrade? You mean re-write.
- tossup8536 7y ago
  Java 1 could actually be progressively migrated to up to date java 11. It would have been a fantastic choice if they had started a reimplantation. (Unless performance was an issue)
msla 7y ago
Here's some simple COBOL code: http://www.csis.ul.ie/cobol/examples/Conditn/Conditions.htm http://www.csis.ul.ie/cobol/examples/Conditn/Conditions.htm identification division. program-id. letters. data division. working-storage section. 01 Char PIC X. 88 Vowel VALUE "a", "e", "i", "o", "u". 88 Consonant VALUE "b", "c", "d", "f", "g", "h" "j" THRU "n", "p" THRU "t", "v" THRU "z". 88 Digit VALUE "0" THRU "9". 88 ValidCharacter VALUE "a" THRU "z", "0" THRU "9". procedure division. begin. display "Enter lower-case character or digit. No data ends.". accept Char. perform until not ValidCharacter evaluate true when Vowel display "The letter " Char " is a vowel." when Consonant display "The letter " Char " is a consonant." when Digit display Char " is a digit." when other display "problems found" end-evaluate accept Char end-perform stop run. (I removed some chaff which GnuCOBOL doesn't need and fixed an apparent bug.) So... where is it actually testing what kind of character you input? Where is the code for that? You input a specification for what a Vowel is, for example, and you write explicit code for what to do when a Vowel is input, but where is the code which goes through the specification and decides, yep, that's a Vowel? COBOL is kind of an odd language. It's verbose in some respects and quite concise in others. Rewriting COBOL into something else would take actual human effort if you wanted the "something else" to look like code a human wrote, as opposed to the intermediate pass of an optimizing compiler, which is what the C GnuCOBOL can output looks like. Re-writing the COBOL might be the best move in some cases, or replacing it with entirely new code, but it isn't something you'd be able to do "for free" in any sense, especially with regards to time.
- metreo 7y ago
  It's actually still better on my eyes than JavaScript.
- number6 7y ago
  Never saw cobol in my life before, guess its "evaluate true when" part. not very explicit but readable. maybe it's just a well written example but something to work with
- 7y ago
DarthGhandi 7y ago
If it was open sourced there'd probably be some willing to modernise the system for free. Govt IT systems and procurement are such a mess, putting it all out there for people to review and complain about is the only way it'll ever get better.
YeGoblynQueenne 7y ago
>> I don't want to sound condescending but why can't these systems be rewritten in a modern language? Cobol was a modern language 50 years ago. Python will be an ancient language 50 years from now. What do we do? Keep rewriting everything every 50 years? 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. This is no joke. Given that most of the Cobol running today is running on mainframes at banks and card networks and the like, "a new bug" may translate to a few hundred thousand dollars of losses. There's no point in building a new house of cards every few decades.
- hordeallergy 7y ago
  Can the hardware not be upgraded? The article says the system is struggling with 400k people a week in new York. That's terribly slow. No overclocking?
- number6 7y ago
  Thanks for your comment, that's something I can relate. Somehow I think C or C++ wouldn't run into the same problem while I can see this happen to python.
- ptx 7y ago
  But every change to the Cobol codebase carries a risk of introducing new bugs (and presumably there are changes if they employ programmers to work on it) so if a newer language and platform makes changes easier and less risky it could still be a win.
- Cyberdog 7y ago
  > 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.
soneil 7y ago
The problem with these systems is rarely the language itself. It's that they're spaghetti monoliths - with decades of growth and tangles. And it's really difficult to overstate monolith here - government and finance are often the Himalayan examples, monoliths on tectonic scales. The closest that modern design patterns come to these systems, is using them as the nightmarish example that justifies why modern practices exist. It's rarely actually a technological problem. It's scale, scope, documentation, budget and motivation. You have to take Mount Everest, and carve it into 2 million separate boulders. Document every single one of them. Paint some of them. Replace some of them with stronger materials. If any of them move, you failed. If any snow is disturbed, you failed. If the climbers even notice this is happening, or has happened, you've failed. And on top of this herculean feat, the person paying for it needs to understand that despite the insane cost of this endeavour, he's probably not going to see a single benefit - but his successor in 10-20 years will. But if you fail, he's going to feel that hard and fast.

jimbob45 7y ago

They’d have to be revalidated. Don’t fix it if it’s not broken. Edit: and when do you upgrade? If they upgraded in ‘85, it would be in C++. ‘95, and it would be Java 1.0. ‘05 and it would have been VB6. None of those would have been substantially better save that they would have been easier to hire maintenance programmers for.

luckylion 7y ago
And now that they're broken, they can't be fixed. ;) With so many legacy systems that are often in very important places, I wonder whether it wouldn't be smarter to spend money on systems converting a modern language to cobol, e.g. python2cobol. Is that impossible?
- number6 7y ago
  I guess there are technical reasons. a big bank does risk assessment. I can't imagine a problem like this will go unnoticed for long
number6 7y ago
Ok got it. But it seems to be broken somehow if they need programmers now. Maybe write the tests first so it can be validated easier?
ghayes 7y ago
C++ or Java seem like great alternatives. And I don't get the reference to VB6-- in 2005, it would still have been Java, and in 2015.
bluedino 7y ago
Upgrade? You mean re-write.
tossup8536 7y ago
Java 1 could actually be progressively migrated to up to date java 11. It would have been a fantastic choice if they had started a reimplantation. (Unless performance was an issue)

msla 7y ago

Here's some simple COBOL code: http://www.csis.ul.ie/cobol/examples/Conditn/Conditions.htm http://www.csis.ul.ie/cobol/examples/Conditn/Conditions.htm identification division. program-id. letters. data division. working-storage section. 01 Char PIC X. 88 Vowel VALUE "a", "e", "i", "o", "u". 88 Consonant VALUE "b", "c", "d", "f", "g", "h" "j" THRU "n", "p" THRU "t", "v" THRU "z". 88 Digit VALUE "0" THRU "9". 88 ValidCharacter VALUE "a" THRU "z", "0" THRU "9". procedure division. begin. display "Enter lower-case character or digit. No data ends.". accept Char. perform until not ValidCharacter evaluate true when Vowel display "The letter " Char " is a vowel." when Consonant display "The letter " Char " is a consonant." when Digit display Char " is a digit." when other display "problems found" end-evaluate accept Char end-perform stop run. (I removed some chaff which GnuCOBOL doesn't need and fixed an apparent bug.) So... where is it actually testing what kind of character you input? Where is the code for that? You input a specification for what a Vowel is, for example, and you write explicit code for what to do when a Vowel is input, but where is the code which goes through the specification and decides, yep, that's a Vowel? COBOL is kind of an odd language. It's verbose in some respects and quite concise in others. Rewriting COBOL into something else would take actual human effort if you wanted the "something else" to look like code a human wrote, as opposed to the intermediate pass of an optimizing compiler, which is what the C GnuCOBOL can output looks like. Re-writing the COBOL might be the best move in some cases, or replacing it with entirely new code, but it isn't something you'd be able to do "for free" in any sense, especially with regards to time.

metreo 7y ago
It's actually still better on my eyes than JavaScript.
number6 7y ago
Never saw cobol in my life before, guess its "evaluate true when" part. not very explicit but readable. maybe it's just a well written example but something to work with
7y ago

DarthGhandi 7y ago

If it was open sourced there'd probably be some willing to modernise the system for free. Govt IT systems and procurement are such a mess, putting it all out there for people to review and complain about is the only way it'll ever get better.

YeGoblynQueenne 7y ago

>> I don't want to sound condescending but why can't these systems be rewritten in a modern language? Cobol was a modern language 50 years ago. Python will be an ancient language 50 years from now. What do we do? Keep rewriting everything every 50 years? 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. This is no joke. Given that most of the Cobol running today is running on mainframes at banks and card networks and the like, "a new bug" may translate to a few hundred thousand dollars of losses. There's no point in building a new house of cards every few decades.

hordeallergy 7y ago
Can the hardware not be upgraded? The article says the system is struggling with 400k people a week in new York. That's terribly slow. No overclocking?
number6 7y ago
Thanks for your comment, that's something I can relate. Somehow I think C or C++ wouldn't run into the same problem while I can see this happen to python.
ptx 7y ago
But every change to the Cobol codebase carries a risk of introducing new bugs (and presumably there are changes if they employ programmers to work on it) so if a newer language and platform makes changes easier and less risky it could still be a win.
Cyberdog 7y ago
> 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.

soneil 7y ago

The problem with these systems is rarely the language itself. It's that they're spaghetti monoliths - with decades of growth and tangles. And it's really difficult to overstate monolith here - government and finance are often the Himalayan examples, monoliths on tectonic scales. The closest that modern design patterns come to these systems, is using them as the nightmarish example that justifies why modern practices exist. It's rarely actually a technological problem. It's scale, scope, documentation, budget and motivation. You have to take Mount Everest, and carve it into 2 million separate boulders. Document every single one of them. Paint some of them. Replace some of them with stronger materials. If any of them move, you failed. If any snow is disturbed, you failed. If the climbers even notice this is happening, or has happened, you've failed. And on top of this herculean feat, the person paying for it needs to understand that despite the insane cost of this endeavour, he's probably not going to see a single benefit - but his successor in 10-20 years will. But if you fail, he's going to feel that hard and fast.