←back to thread

127 points Anon84 | 6 comments | | HN request time: 0.231s | source | bottom
Show context
ufmace ◴[] 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 ◴[] 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 #
jacquesm ◴[] No.38510187[source]
COBOL is pretty easy to learn. The problem is that it is so full of archaic nonsense (less so with the more recent versions) that you will be tearing your hair out and wishing for something more modern.

COBOL's main value is in maintaining a pile of legacy codebases, mostly in fintech and insurance that are so large and so old that rewriting them is an absolute no-go. These attempts at cross compiling are a way to get off the old toolchain but they - in my opinion - don't really solve the problem, instead they add another layer of indirection (code generation). But at least you'll be able to run your mangled output on the JVM for whatever advantage that gives you.

With some luck you'll be running a hypervisor that manages a bunch of containers that run multiple JVM instances each that run Java that was generated from some COBOL spaghetti that nobody fully understands. If that stops working I hope I will be far, far away from the team that has to figure out what causes the issue.

It is possible that someone somewhere is doing greenfield COBOL development but I would seriously question their motivations.

replies(2): >>38510508 #>>38512334 #
phasetransition ◴[] No.38512334[source]
Son of a COBOL dev... All this virtualization mess, minus the extra Java layer, started back in the 90s, courtesy of Unisys. I remember my dad pulling his hair out when I was in High School, though I did not understand why back then.
replies(1): >>38512622 #
1. jacquesm ◴[] No.38512622[source]
I think you get it now though. I've seen this whole industry up close for the last 40 years or so and it's absolutely incredible how we went from a machine with 32 M of RAM and 300 M of storage sufficient to serve 1400 branch offices of a bank to a phone with a very large multiple of that, that can barely serve a single user.
replies(2): >>38514201 #>>38514543 #
2. snotrockets ◴[] No.38514201[source]
That phone does a lot more than the bank mainframe used to do.
replies(2): >>38514345 #>>38514457 #
3. g805 ◴[] No.38514345[source]
"Busy" and "useful" are entirely different things. Maybe all that extra capability would be better spent elsewhere.
4. jazzyjackson ◴[] No.38514457[source]
> iphone hangs while trying to match "blu" up with "bluetooth settings"

So many background tasks, much computation

5. mrweasel ◴[] No.38514543[source]
That is some thing that I can't stop thinking about. I get that banking software does more, like online banking, larger transaction volume, more account and loan types, but why is it that we can not run a small to medium bank on a single modern CPU and 1TB of memory?
replies(1): >>38522587 #
6. jacquesm ◴[] No.38522587[source]
Eye candy. Endless abstraction layers.