←back to thread

Watsonx: IBM's code assistant for turning COBOL into Java

(www.pcmag.com)
127 points Anon84 | 1 comments | 03 Dec 23 16:31 UTC | HN request time: 0.205s | source
Show context
ufmace ◴[03 Dec 23 17:53 UTC] No.38509082[source]▶
The article title is clickbaity, but the actual point is the proposal of using LLMs to translate large amounts of legacy COBOL systems to more modern languages like Java. Doesn't seem terribly useful to me. I expect you could get a 90% solution faster, but the whole challenge with these projects is how to get that last bit of correctness, and how to be confident enough in the correctness of it to actually use it in Production.

But then all of this has been known for decades. There are plenty of well-known techniques for how to do all that. If they haven't actually done it by now, it's a management problem, and no AI tech is going to fix that.

replies(11): >>38509198 #>>38509418 #>>38509802 #>>38509995 #>>38510231 #>>38510273 #>>38510431 #>>38511157 #>>38511186 #>>38512486 #>>38512716 #
matthewdgreen ◴[03 Dec 23 18:03 UTC] No.38509198[source]▶
How hard is it to actually learn COBOL? It seems like a fairly simple language to pick up, but maybe the idiomatic COBOL used in these legacy systems is particularly nasty for some reason.
replies(5): >>38509221 #>>38509476 #>>38509483 #>>38510105 #>>38510187 #
the_only_law ◴[03 Dec 23 18:05 UTC] No.38509221[source]▶
Learning COBOL is the easy part. My understanding is the hard part is becoming familiar with insanely expensive, proprietary mainframe platform that’s you’ll find in most COBOL work. I know IBM has some sort of self training material, but I’m not sure if it’s enough to go from zero to qualified. Most work I see in the area seems to want established domain experts, not hackers who learn just enough to be dangerous.
replies(3): >>38509507 #>>38511265 #>>38516948 #
1. specialist ◴[04 Dec 23 13:31 UTC] No.38516948[source]▶
I briefly helped with some mainframe/legacy modernization work.

Their hard part was determining which feeds and datasets were still needed by someone, somewhere. Over the decades, 100s were created as needed (ad hoc). No inventory. No tooling (monitoring, logging) to help. It's likely only a handful were still needed, but no telling which handful.

The bosses were extremely risk adverse. eg "We can't turn that off, someone might be using it."

I suggested slowly throttling all the unclaimed (unknown) stuff over time. Wouldn't break anything outright. But eventually someone would squeal once they noticed their stuff started lagging. Then incrementally turn things off. See if anyone notices. Then outright remove it.

Nope. No can do. Too risky.