4 ms·

This is true, but the niche should be a dev who knows COBOL IRL enough to translate to something newer. Much of the COBOL I've seen would be trivial to rewrite

This is true, but the niche should be a dev who knows COBOL IRL enough to translate to something newer. Much of the COBOL I've seen would be trivial to rewrite, just nobody wants to tackle it. A person who 1) Can read cobol 2) can communicate well with stakeholders and 3) can translate to NodeJS/Python/.NET should be able to fit this niche pretty well. I've done this before - translate green screen apps to ASP.NET. In my case, the company had (retiring) IT staff read the cobol and give us good "plain english". The actual ASP.NET code was trivial. That said, my one caveat is I don't feel like any language today has the longevity of these systems. That code was ASP.NET 3 MVC - new at the time, but outdated now. What stack do I pick today that will still be running in 30 years? HTML+JS+NodeJS seems the most likely candidate IMO, but then you get into the various frameworks-du-jur and it sort of falls apart. Would love HN opinions.

goodpoint 4y ago
Some banks tried to jump on the Java bandwagon when it was the hyped up thing of the moment and now many are going back to COBOL. > HTML+JS+NodeJS seems the most likely candidate IMO So that my bank can run npm install leftpad on their payment processors. Please tell me this is parody.
- shireboy 4y ago
  Hah, well, right. I just meant from a longevity standpoint. What stack can I use today that is and will continue to be well supported for 30+ years?
  - canon123456 4y ago
  - jhugo 4y ago
    C, C++, probably Rust, various other relatively boring languages. If Node.js is even still used in 30 years it won't look anything like today's Node.js.
  - djbusby 4y ago
    I've converted some legacy apps into, not a joke, PHP3. In like 2006-8. So, PHP3 still works this many years later (in VMs). Currently working to migrate to PHP7. It's just moving business data into and out of, in many cases still file based records (but maybe we can upscale to SQL). So, if you can read the COBOl and implement correctly in the next blessed language (with tests). Harder part is to meet the folks that can get you those gigs than actually doing the gigs.
  - goodpoint 4y ago
    Come on, are you serious? COBOL is still being used exactly because it does not have a high-churn ecosystem. Same for C and C++. Of all languages, js is by far the most volatile.
- absove 4y ago
  > Some banks tried to jump on the Java bandwagon when it was the hyped up thing of the moment and now many are going back to COBOL. What's wrong with Java that COBOL doesn't suffer from exactly?
goatlover 4y ago
What makes you think HTML/JS/Node will be anything like it is today 30 years from now?
- jazzyjackson 4y ago
  they are good enough same reason we are flying 737 aircraft and chinook helicopters, well after we tried concordes and space shuttles. see "Web Design: the first 100 years" for more: https://idlewords.com/talks/web_design_first_100_years.htm https://idlewords.com/talks/web_design_first_100_years.htm
pc86 4y ago
> What stack do I pick today that will still be running in 30 years? This is such a backward mindset, though. Software evolves. Ecosystems evolve. Perhaps most importantly, security risks and surface areas evolve (which in part necessitates the prior points). There is no good reason for systems to stagnate over three decades. Software isn't construction, it's gardening, and it requires constant maintenance and attention.
- ElectricalUnion 4y ago
  > Software isn't construction, it's gardening, and it requires constant maintenance and attention. Software is like construction, you don't demolish everything and start from scratch just because it's a little, or very old. Discarding everything and rewriting in another language is a expensive and error prone process. To cite the excellent Joel blog: > the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch. https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
  - pc86 4y ago
    Where did I suggest rewriting things from scratch?
hyperman1 4y ago
Some killers here are the data model and the unknown edge cases. And the size. The data model is fixed width flatfiles with very specific access and index methods. There are 50 years of workarounds applied in there. Whatever code you end up with will still need to communicate with all the other stuff, so the data model can't change untill you got everything touching it in the new language. The edge cases are a second problem. The code runs well in a very practical sense, as every major bug relevant for the end user has been fixed or worked around ages ago. Or it became the correct behaviour by sheer overwhelming force. You replace something insane, then find out you broke another system that had counterbalancing insanity. Worst case, it will run for a few months, silently corrupting data. Next tax round or year end, some report says something strange, and subsequent troubleshooting uncovers major doodoo. No, the taxman wont wait on your bugfix. Then there is the sheer volume of code. 10 million lines is small scale. You can spend your whole carreer rewriting everything in the most trivial way, and 40 year later find you're not even close to done. There will be multiple failed rewrites in there, causing massive lavaflow architecture problems.

goodpoint 4y ago

Some banks tried to jump on the Java bandwagon when it was the hyped up thing of the moment and now many are going back to COBOL. > HTML+JS+NodeJS seems the most likely candidate IMO So that my bank can run npm install leftpad on their payment processors. Please tell me this is parody.

shireboy 4y ago
Hah, well, right. I just meant from a longevity standpoint. What stack can I use today that is and will continue to be well supported for 30+ years?
- canon123456 4y ago
- jhugo 4y ago
  C, C++, probably Rust, various other relatively boring languages. If Node.js is even still used in 30 years it won't look anything like today's Node.js.
- djbusby 4y ago
  I've converted some legacy apps into, not a joke, PHP3. In like 2006-8. So, PHP3 still works this many years later (in VMs). Currently working to migrate to PHP7. It's just moving business data into and out of, in many cases still file based records (but maybe we can upscale to SQL). So, if you can read the COBOl and implement correctly in the next blessed language (with tests). Harder part is to meet the folks that can get you those gigs than actually doing the gigs.
- goodpoint 4y ago
  Come on, are you serious? COBOL is still being used exactly because it does not have a high-churn ecosystem. Same for C and C++. Of all languages, js is by far the most volatile.
absove 4y ago
> Some banks tried to jump on the Java bandwagon when it was the hyped up thing of the moment and now many are going back to COBOL. What's wrong with Java that COBOL doesn't suffer from exactly?

goatlover 4y ago

What makes you think HTML/JS/Node will be anything like it is today 30 years from now?

jazzyjackson 4y ago
they are good enough same reason we are flying 737 aircraft and chinook helicopters, well after we tried concordes and space shuttles. see "Web Design: the first 100 years" for more: https://idlewords.com/talks/web_design_first_100_years.htm https://idlewords.com/talks/web_design_first_100_years.htm

pc86 4y ago

> What stack do I pick today that will still be running in 30 years? This is such a backward mindset, though. Software evolves. Ecosystems evolve. Perhaps most importantly, security risks and surface areas evolve (which in part necessitates the prior points). There is no good reason for systems to stagnate over three decades. Software isn't construction, it's gardening, and it requires constant maintenance and attention.

ElectricalUnion 4y ago
> Software isn't construction, it's gardening, and it requires constant maintenance and attention. Software is like construction, you don't demolish everything and start from scratch just because it's a little, or very old. Discarding everything and rewriting in another language is a expensive and error prone process. To cite the excellent Joel blog: > the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch. https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
- pc86 4y ago
  Where did I suggest rewriting things from scratch?

hyperman1 4y ago

Some killers here are the data model and the unknown edge cases. And the size. The data model is fixed width flatfiles with very specific access and index methods. There are 50 years of workarounds applied in there. Whatever code you end up with will still need to communicate with all the other stuff, so the data model can't change untill you got everything touching it in the new language. The edge cases are a second problem. The code runs well in a very practical sense, as every major bug relevant for the end user has been fixed or worked around ages ago. Or it became the correct behaviour by sheer overwhelming force. You replace something insane, then find out you broke another system that had counterbalancing insanity. Worst case, it will run for a few months, silently corrupting data. Next tax round or year end, some report says something strange, and subsequent troubleshooting uncovers major doodoo. No, the taxman wont wait on your bugfix. Then there is the sheer volume of code. 10 million lines is small scale. You can spend your whole carreer rewriting everything in the most trivial way, and 40 year later find you're not even close to done. There will be multiple failed rewrites in there, causing massive lavaflow architecture problems.