4 ms·

Banking... - Does that COBOL code do the thing(s) it's supposed to in a reliable and 100% predictable way? My guess is : Yes it does. So let's go down your p

Banking... - Does that COBOL code do the thing(s) it's supposed to in a reliable and 100% predictable way? My guess is : Yes it does. So let's go down your path. You rewrite that COBOL program using your hot new recent language of choice. How many new bugs will be introduced? What other risks are there in this new language; CVEs? RCEs? Simple coding bugs which could cost that bank millions/billions/trillions - or just as bad, the bank's customers their savings/livelihoods? Which New Hotness language would you rewrite that crusty old COBOL application in? Rust? [0] Golang? [1] Something else? There are times when it's better to leave the New Hotness to some new application rather than trying to replace a known reliable/predictable system with New Hotness. Especially for banking. [0] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust [1] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=golang https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=golang

Moto7451 5y ago
Every couple of years someone at work rewrites the email sending code in a new sexy language and reimplements the same 7 bit encoding bugs as well as other subtle email encoding issues. This happens even with ample documentation and code comments about why specific conditionals are set.
- SenHeng 5y ago
  If a bug has been around long enough and often used, it is an undocumented feature that becomes a documented feature in the next rewrite.
ggm 5y ago
I guess you're on the other side of the fence. I don't dispute that the code can be fine.. but Y2K is strongly applicable here. I would personally worry if my financial institution depended on a bytecode interpreter to run Cobol for a dead OS rather than reimplement. Rust might be the sexy language but surely Erlang or Haskell would be the wise choices?
makeitdouble 5y ago
I mostly agree with your take. To jest, the other side of the coin is when you have a legit and critical reason to move your stack forward, it will be way harder than if you moved along with the times. The same way moving from a Solaris system from 6 decades ago comes with heavier costs and is risquier than from some old Redhat. For the bank example, if you’re given another system to sync with and you’re still full COBOL, I’d assume it’s just a whole world of pain for years and years. Meanwhile the other banks move forward and integrate newer systems way faster and in more secure ways than you do, directly affecting your business.
- cudgy 5y ago
  Highly unlikely they will integrate newer systems in more secure ways using a new, unfamiliar language. In fact, many of the new platforms are becoming more of a black box that developers are unable to fix or understand when they need to fix or even recognize critical faults. Big bang rewrites are dangerous, gradual migration is a better plan for larger systems.
  - makeitdouble 5y ago
    > Big bang rewrites are dangerous, gradual migration is a better plan for larger systems. I think we're on the same page. Yes, it needs to be gradual, and devs need to become familiar with new languages, which is why I am proponent of slowly "modernize" old stacks even if there is no immediate need to do it.

Moto7451 5y ago

Every couple of years someone at work rewrites the email sending code in a new sexy language and reimplements the same 7 bit encoding bugs as well as other subtle email encoding issues. This happens even with ample documentation and code comments about why specific conditionals are set.

SenHeng 5y ago
If a bug has been around long enough and often used, it is an undocumented feature that becomes a documented feature in the next rewrite.

ggm 5y ago

I guess you're on the other side of the fence. I don't dispute that the code can be fine.. but Y2K is strongly applicable here. I would personally worry if my financial institution depended on a bytecode interpreter to run Cobol for a dead OS rather than reimplement. Rust might be the sexy language but surely Erlang or Haskell would be the wise choices?

makeitdouble 5y ago

I mostly agree with your take. To jest, the other side of the coin is when you have a legit and critical reason to move your stack forward, it will be way harder than if you moved along with the times. The same way moving from a Solaris system from 6 decades ago comes with heavier costs and is risquier than from some old Redhat. For the bank example, if you’re given another system to sync with and you’re still full COBOL, I’d assume it’s just a whole world of pain for years and years. Meanwhile the other banks move forward and integrate newer systems way faster and in more secure ways than you do, directly affecting your business.

cudgy 5y ago
Highly unlikely they will integrate newer systems in more secure ways using a new, unfamiliar language. In fact, many of the new platforms are becoming more of a black box that developers are unable to fix or understand when they need to fix or even recognize critical faults. Big bang rewrites are dangerous, gradual migration is a better plan for larger systems.
- makeitdouble 5y ago
  > Big bang rewrites are dangerous, gradual migration is a better plan for larger systems. I think we're on the same page. Yes, it needs to be gradual, and devs need to become familiar with new languages, which is why I am proponent of slowly "modernize" old stacks even if there is no immediate need to do it.