Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AI migrated legacy COBOL programs to Java, bugs included

arxiv.org

Post reply on HN
Print view View original

101–108 of 108 posts

Re: AI migrated legacy COBOL programs to Java, bugs included

#101

Post by pjmlp »

Leonard_of_Q wrote: post #58
mtct88 wrote: post #35

Why should I convert COBOL to Java? LLM can write COBOL just as fine.

Because humans don't want to spend time to learn how to use "dead" languages and humans still play a role in programming. Having LLMs churn out more COBOL instead of Java means more of the code base becomes 'terra incognita' for the involved humans. Learning COBOL isn't that hard - which was one of its stated purposes - but it is still seen as decidedly 'uncool' and 'legacy'. Maybe the increased role of LLMs in codin…

The irony is that talking to AI could not be any closer than COBOL's original goal.

Re: AI migrated legacy COBOL programs to Java, bugs included

#102

Post by pjmlp »

Surac wrote: post #20

How does ai implement all the not Cobol parts a Cobol program rely on? Job Contol, CICS, sort processors? Cobol and mainframe technologies are non existant in java on any modern machine

If the systems are to stay on mainframe/micro land, all IBM, Fujitsu, Unisys platforms support Java.

This is one set of ecosystems, where .NET going cross platform still misses out to Java, and neither of those companies cares about supporting it on their platforms.

There are some half way supported Python, Go and Rust versions as well, although I think they need the "WSL" of the respective mainframe/micro OS, aka UNIX services.

Re: AI migrated legacy COBOL programs to Java, bugs included

#103

Post by pjmlp »

raverbashing wrote: post #19
anthk wrote: post #18

COBOL is not about the language, it's about the whole environment in the mainframe. LLM fanboys won't understand this. You need something like a mainframe with a 99.99% uptime no matter what happens in hardware, with live CPU swapping and such.

Yes and that mainframe runs several other technologies besides COBOL, and more importantly, that don't depend on it (COBOL fanboys won't understand this ;) )

Given the option, I would go with DB 2 on z/OS instead of COBOL, for example.

Re: AI migrated legacy COBOL programs to Java, bugs included

#104

Post by DarkUranium »

Oxodao wrote: post #71
DarkUranium wrote: post #62

Earlier quoted context omitted.

I know it's not the only problem (but it is IMO the main one), but this is why I'm a proponent of allowing operator overloading in languages. Yes, you can't tell at a glance if `+` really still does what it should, but I find that problem no different from a library mis-naming a function and/or said function having strange side-effects. `+` should do addition, period . No, not even concatenation if possible (I do fin…

php has a separate `.` operator that concatenate and you get an error if you try to do it with a `+`. That's indeed better but most of the time you concatenate with `sprintf` anyway

Yes, and it's a surprising good part about PHP (a language that otherwise has an enormous collection of warts, to put it mildly).

I feel like the more dynamic and/or weakly-typed the language is, the more important it is to have a separate concat operator.

The worst ones being weakly-typed and dynamic. Consider `'5' + '10'` in JavaScript vs `'5' - '10'`. I also very much dislike Python's `+` for concat, but at least it's more strongly typed.

PHP, Lua, and Erlang are three examples of dynamically-typed languages with separate concat operators (`.`, `..`, `++`; respectively), and they all are better for it.

That said, even statically-typed languages benefit greatly from it. Maybe if C++ had a concat operator, it'd never end up abusing `For example, D uses `~` in infix for concat. Even UnrealScript, a 1990s game-engine-specific language (which tend to be a mess in general) did this right (it uses `$` or `@` --- with `a @ b` being equivalent to `a $ " " $ b`, IIRC).

Re: AI migrated legacy COBOL programs to Java, bugs included

#105

Post by dragonwriter »

win311fwg wrote: post #38
dragonwriter wrote: post #29

Earlier quoted context omitted.

> The only realistic low-error approach is incremental step-by-step migration using Cursor or similar tools. Correction: AI is not deterministic, the only realistic low-error solution is not a more complex use of non-deterministic AI, but deterministic transpilation. The problem is that this results in COBOL-in-Java which runs correctly but it is a nightmare to maintain.

AI (LLMs) is typically not run deterministically for performance reasons, but can be turned deterministic if you want it to be. The output will still be probabilistic, however, so you will be no further ahead. Determinism isn't helpful.

You are, of course, correct about determinism. In the grandparent post I was accepting the previous poster’s somewhat sloppy use of “nondeterministic” because I was focussed on other aspects of the discussion.

Re: AI migrated legacy COBOL programs to Java, bugs included

#106

Post by ASalazarMX »

Yopolo wrote: post #98
ASalazarMX wrote: post #86

Earlier quoted context omitted.

But, hear me out, a COBOL to Java migration absolutely needs to be deterministic. Surviving COBOL programs run a lot of sensitive operations. As a side note, I can't fathom why they chose Java. It's easier to teach COBOL to a competent engineer than to rewrite everything in a language that encourages onion architectures. Why not Go, for example?

Java as a programming language doesn't enforce any architecture. There is no difference to go. Its a system of folders. The tests need to be green, the math needs to math, but the code can look a little bit different here or there. I don't think its easy at all to educate someone on COBOL. Its carrier suicide if you want to ever do anything else again after that gig. I was writing java for years, switched for 2 years…

As someone that has worked at a bank maintaining RPG/COBOL and Java, the latter definitely encourages programmers to wrap things in yet another class. They think they're simplifying, but in reality, they're piling abstraction layers that have to be peeled off one by one when, for example, you're tring to find that EBCDIC-to-UTF8 bug.

A good Java architecture is possible, though, but it requires planning, discipline, and restraint; and yet the ever-changing business needs can mar your beautiful castle given enough time. COBOL is simpler and more straightforward, you have to go out of your way to mess it as badly as Java allows.

Re: AI migrated legacy COBOL programs to Java, bugs included

#108

Post by pixel_popping »

m4rtink wrote: post #65
someone654 wrote: post #45

Earlier quoted context omitted.

> 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.

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.

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.
Post reply on HN