6 ms·

Before, only the senior cobol programmers at the company understood and knew the codebase. Now, no one does. I can see the allure of moving away from a legacy

Before, only the senior cobol programmers at the company understood and knew the codebase. Now, no one does. I can see the allure of moving away from a legacy cobol system. But an AI rewrite doesn't actually solve any of the issues with having a legacy cobol codebase. You just have a new system no one knows or understands.

someone654 2mo ago
> Now, no one does. I got a chuckle over this, but in my experience working on legacy systems, this is the case already. Using AI to translate/explain the code brings extra understanding.
- Zenst 2mo ago
  Whilst true, it's not without its gotchas, and I saw a video the other day that elegantly highlights this: https://www.youtube.com/watch?v=t6MAZW-joCo https://www.youtube.com/watch?v=t6MAZW-joCo. A false sense of confidence is bad; one that is offloaded onto somebody else is another.
- m4rtink 2mo ago
  Can it really explain the code if the information is not there anymore ? It was in a binder that got shredded 40 years ago by accident. More like it will hallucinate some explanation & cause even more confusion.
  - free_bip 2mo ago
    If what you want is the "Why", you're right it probably won't get it right. It'll just give you baseless speculation. But if what you want is the "What" or the "How", I think it can be useful.
  - sharts 2mo ago
    The code is the information. If you need binders of info then it wasn’t codified
  - pixel_popping 2mo ago
    Yes, it would take a long time for humans to remake a documentation from the codebase itself, but AI could do that much quicker and with close to perfect accuracy, Code is superior to documentation as it's the direct intended behavior (including bugs), in a sense, we won't even need documentation in the future, except maybe to lower AI costs.
Zenst 2mo ago
Having worked in COBOL extensivly in the 80s and 90s, as well as working for a software house that did migrations (Craziest was Plan assembler to Dec Vax C). I do wonder how an ambitious AI would handle the maths. COBOL is renowed for its fixed no rounding maths, utterly rigid and defined in the code, Java on the other hand is not (e.g., 0.1 + 0.2 becomes 0.30000000000000004), unless they are extensivly using BigDecimal, then its already a broken migration. I've seen projects proclaim in the past to migrate COBOL systems to Java, and fail expicly when the solution was a dtaawarehouse system and a seperate Java system using the legacy backend to do all the fancy marketing reports or whatever other department was pushing for changes they wanted without a grasp of what it truly entailed and blinded by some sales pitch. It's not just the code that needs migrating, its the data as well, then you want solid robust infrastrucure, which is why IBM still sell those mainframes to run all that well battle tested COBOL code. Is it impossible to migrate to Java or any othger language - no, anything can be done, but the level of devil in the details and not just software, the data and a robust system to run it upon. It is very easy for even the best to overlook a gotcha. We have all used an AI where it has gone down one path and you then point out something and it corrects itself, without the knowledge and a load of old grey beads(or a team) to act as devil advocate and try to pull the output apart, YOU can end up with something that works for everyones satisfaction, but is hiding a few gotchas down the line. AI coding needs a full debate team with one puishing it and one countering it almost I'd say. If it works, why change it is always a good approach and why we mostly have in certain systems a COBOL backend with APIs or datawarehousing to expose for fancy java or other language added value/functionality. I can only image generations of directors pushing cutting edge to replace legacy systems, and learning that cutting edge can cut you. My sympathy for the IT departments who have to deal with that as it has always been a bain of IT departments who are then forced to justify why it's fooling in a constructive way and explain it to non IT people in upper managment why the case. As for migrating COBOL to anything, I'd not do it myself, id suggest a rewrite/redesign of a new system from scratch and then run both in parallel for a long time and make sure they actually do the same job and results. Even hand migrating back in the day, would produce a lot of messy code that refactoring would make sence and yet, not what the client would pay for as that would be a rewrite.
- edflsafoiewq 2mo ago
tonyhart7 2mo ago
"Now, no one does." well, we just need to learn the rewrite then ???
- jraph 2mo ago
  Yeah, "We are looking for a developer specialized in critical Java code following idiomatic COBOL which hasn't been tested in production yet and which nobody is sure about whether the exact behavior matches what's been running in production. You will enjoy meaningful work in an environment which has been considering engaging in environmental concerns for decades and which caries the well-being and social condition of fellow human beings as a core values, directly addressing your middle age existential crisis. Extra bonus points if you like using LLMs. The pay is good, but remember you are a Java developer, not a COBOL developer, and also remember we are already paying for tokens to do your job. Those are also possibly getting more and more expensive so we'll see about the raises. Job starts as soon as possible."
- glimshe 2mo ago
  The problem isn't as much understanding what the code does (that's hard but not impossible), but understanding why that duplicate INSERT into the database is needed. The guy who no longer works at the company knew it was because of a bug in the DB that wasn't fixed by the vendor after the company cancelled the maintenance contract due to financial difficulties during the great recession. AI doesn't and can't know that. So AI proposes to "fix the bug as we port it" and remove the double INSERT. The CTO sends an email saying that the new AI fixed 174 bugs during the porting process and now the company has a much better and resilient system. BREAKING NEWS: thousands of travelers can't get go back home after thanksgiving due to a computer glitch that accidentally cancelled their return tickets. Stay tuned to our live coverage!
  - tonyhart7 2mo ago
    nah you just make it hyperbole
Yopolo 2mo ago
Start extracting specs from the codebase. Prompt the core architecutre well suited for it. Let it write tests. Let it vibe migrate from left to write. Now you at least have a chance of a team being able to work on that code base and actually clean it up and make it good. Cobold is hard, hard legacy with bad tooling.
hn_submit 2mo ago
Wasn't COBOL invented to read like business prose and be easily understood by programmers and non-programmers alike? If developers are able to write COBOL code no one understands than it failed its main objective. IMHO every large software system should be developed on the basis of clear and concise functional specifications so everyone can understand what the software does and how it does so at a higher functional level.
- YuechenLi 2mo ago
  Cobol code isn't esoteric, but it is designed in a way that is unambiguous and clear about its control flow, but very verbose and tedious to read/write. Translating from Cobol to a modern programming language is trivial for LLMs for that reason because the lack of any hidden state functionalities like generics for example.
  - pjmlp 2mo ago
    Modern Cobol has most of the goodies, it is much more feature rich than Go.
- acdha 2mo ago
  Your last paragraph is getting at the core problem: COBOL _is_ easy to understand and write at the language level but what keeps people on these systems is decades of accumulated business rules, and it’s almost certain that there’s no accurate spec for the whole system. You might have some overall documentation but I’d expect to find cases where someone added a special case back in 1987 to handle an edge case and everyone who works in shipping knows there’s something special to do if this usually numeric field starts with a $ sign etc. but it’s not described in some kind of spec.
js8 2mo ago
> Now, no one does. Not true, AI does. It's AI job security...
remify 2mo ago
If you can migrate using a strangle pattern, I can see it working pretty well and fast.
gt0 2mo ago
It seems to me that some companies are looking to move off COBOL and mainframes to say Linux and Java, because that is what someone was employed to do, not because it's necessarily a good idea. I think COBOL systems would be plenty maintainable if the owners of the systems invested in maintaining them. If companies just let people retire, attempt to hire replacements with unremarkable salaries, then maintenance is a problem. If they paid salaries that reflected how critical this work is, I don't think it would be that big a problem to find and keep good developers. We have critical economic infrastructure being treated as annoyance and a cost centre.
- deepsun 2mo ago
  I firmly believe that any thoughtful rewrite is good. Most companies just don't have resources for that. At least, it serves as a security review, but also refreshes team knowledge of the system. They usually also improve documentation if it was wrong.
CyberDildonics 2mo ago
Java should have significantly better tools for trying to understand a program than cobol.
- pjmlp 2mo ago
  It has had for plenty of years now, however many think vi and emacs is enough.

someone654 2mo ago

> Now, no one does. I got a chuckle over this, but in my experience working on legacy systems, this is the case already. Using AI to translate/explain the code brings extra understanding.

Zenst 2mo ago
Whilst true, it's not without its gotchas, and I saw a video the other day that elegantly highlights this: https://www.youtube.com/watch?v=t6MAZW-joCo https://www.youtube.com/watch?v=t6MAZW-joCo. A false sense of confidence is bad; one that is offloaded onto somebody else is another.
m4rtink 2mo ago
Can it really explain the code if the information is not there anymore ? It was in a binder that got shredded 40 years ago by accident. More like it will hallucinate some explanation & cause even more confusion.
- free_bip 2mo ago
  If what you want is the "Why", you're right it probably won't get it right. It'll just give you baseless speculation. But if what you want is the "What" or the "How", I think it can be useful.
- sharts 2mo ago
  The code is the information. If you need binders of info then it wasn’t codified
- pixel_popping 2mo ago
  Yes, it would take a long time for humans to remake a documentation from the codebase itself, but AI could do that much quicker and with close to perfect accuracy, Code is superior to documentation as it's the direct intended behavior (including bugs), in a sense, we won't even need documentation in the future, except maybe to lower AI costs.

Zenst 2mo ago

Having worked in COBOL extensivly in the 80s and 90s, as well as working for a software house that did migrations (Craziest was Plan assembler to Dec Vax C). I do wonder how an ambitious AI would handle the maths. COBOL is renowed for its fixed no rounding maths, utterly rigid and defined in the code, Java on the other hand is not (e.g., 0.1 + 0.2 becomes 0.30000000000000004), unless they are extensivly using BigDecimal, then its already a broken migration. I've seen projects proclaim in the past to migrate COBOL systems to Java, and fail expicly when the solution was a dtaawarehouse system and a seperate Java system using the legacy backend to do all the fancy marketing reports or whatever other department was pushing for changes they wanted without a grasp of what it truly entailed and blinded by some sales pitch. It's not just the code that needs migrating, its the data as well, then you want solid robust infrastrucure, which is why IBM still sell those mainframes to run all that well battle tested COBOL code. Is it impossible to migrate to Java or any othger language - no, anything can be done, but the level of devil in the details and not just software, the data and a robust system to run it upon. It is very easy for even the best to overlook a gotcha. We have all used an AI where it has gone down one path and you then point out something and it corrects itself, without the knowledge and a load of old grey beads(or a team) to act as devil advocate and try to pull the output apart, YOU can end up with something that works for everyones satisfaction, but is hiding a few gotchas down the line. AI coding needs a full debate team with one puishing it and one countering it almost I'd say. If it works, why change it is always a good approach and why we mostly have in certain systems a COBOL backend with APIs or datawarehousing to expose for fancy java or other language added value/functionality. I can only image generations of directors pushing cutting edge to replace legacy systems, and learning that cutting edge can cut you. My sympathy for the IT departments who have to deal with that as it has always been a bain of IT departments who are then forced to justify why it's fooling in a constructive way and explain it to non IT people in upper managment why the case. As for migrating COBOL to anything, I'd not do it myself, id suggest a rewrite/redesign of a new system from scratch and then run both in parallel for a long time and make sure they actually do the same job and results. Even hand migrating back in the day, would produce a lot of messy code that refactoring would make sence and yet, not what the client would pay for as that would be a rewrite.

edflsafoiewq 2mo ago

tonyhart7 2mo ago

"Now, no one does." well, we just need to learn the rewrite then ???

jraph 2mo ago
Yeah, "We are looking for a developer specialized in critical Java code following idiomatic COBOL which hasn't been tested in production yet and which nobody is sure about whether the exact behavior matches what's been running in production. You will enjoy meaningful work in an environment which has been considering engaging in environmental concerns for decades and which caries the well-being and social condition of fellow human beings as a core values, directly addressing your middle age existential crisis. Extra bonus points if you like using LLMs. The pay is good, but remember you are a Java developer, not a COBOL developer, and also remember we are already paying for tokens to do your job. Those are also possibly getting more and more expensive so we'll see about the raises. Job starts as soon as possible."
glimshe 2mo ago
The problem isn't as much understanding what the code does (that's hard but not impossible), but understanding why that duplicate INSERT into the database is needed. The guy who no longer works at the company knew it was because of a bug in the DB that wasn't fixed by the vendor after the company cancelled the maintenance contract due to financial difficulties during the great recession. AI doesn't and can't know that. So AI proposes to "fix the bug as we port it" and remove the double INSERT. The CTO sends an email saying that the new AI fixed 174 bugs during the porting process and now the company has a much better and resilient system. BREAKING NEWS: thousands of travelers can't get go back home after thanksgiving due to a computer glitch that accidentally cancelled their return tickets. Stay tuned to our live coverage!
- tonyhart7 2mo ago
  nah you just make it hyperbole

Yopolo 2mo ago

Start extracting specs from the codebase. Prompt the core architecutre well suited for it. Let it write tests. Let it vibe migrate from left to write. Now you at least have a chance of a team being able to work on that code base and actually clean it up and make it good. Cobold is hard, hard legacy with bad tooling.

hn_submit 2mo ago

Wasn't COBOL invented to read like business prose and be easily understood by programmers and non-programmers alike? If developers are able to write COBOL code no one understands than it failed its main objective. IMHO every large software system should be developed on the basis of clear and concise functional specifications so everyone can understand what the software does and how it does so at a higher functional level.

YuechenLi 2mo ago
Cobol code isn't esoteric, but it is designed in a way that is unambiguous and clear about its control flow, but very verbose and tedious to read/write. Translating from Cobol to a modern programming language is trivial for LLMs for that reason because the lack of any hidden state functionalities like generics for example.
- pjmlp 2mo ago
  Modern Cobol has most of the goodies, it is much more feature rich than Go.
acdha 2mo ago
Your last paragraph is getting at the core problem: COBOL _is_ easy to understand and write at the language level but what keeps people on these systems is decades of accumulated business rules, and it’s almost certain that there’s no accurate spec for the whole system. You might have some overall documentation but I’d expect to find cases where someone added a special case back in 1987 to handle an edge case and everyone who works in shipping knows there’s something special to do if this usually numeric field starts with a $ sign etc. but it’s not described in some kind of spec.

js8 2mo ago

> Now, no one does. Not true, AI does. It's AI job security...

remify 2mo ago

If you can migrate using a strangle pattern, I can see it working pretty well and fast.

gt0 2mo ago

It seems to me that some companies are looking to move off COBOL and mainframes to say Linux and Java, because that is what someone was employed to do, not because it's necessarily a good idea. I think COBOL systems would be plenty maintainable if the owners of the systems invested in maintaining them. If companies just let people retire, attempt to hire replacements with unremarkable salaries, then maintenance is a problem. If they paid salaries that reflected how critical this work is, I don't think it would be that big a problem to find and keep good developers. We have critical economic infrastructure being treated as annoyance and a cost centre.

deepsun 2mo ago
I firmly believe that any thoughtful rewrite is good. Most companies just don't have resources for that. At least, it serves as a security review, but also refreshes team knowledge of the system. They usually also improve documentation if it was wrong.

CyberDildonics 2mo ago

Java should have significantly better tools for trying to understand a program than cobol.

pjmlp 2mo ago
It has had for plenty of years now, however many think vi and emacs is enough.