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

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

pcmag.com

Post reply on HN
Print view View original

111–120 of 186 posts

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

#111

Post by hobs »

credit_guy wrote: post #68
rubyfan wrote: post #58

Earlier quoted context omitted.

> If they haven't actually done it by now, it's a management problem, and no AI tech is going to fix that. This. Further, it’s a failure to continue to disincentivize roles that will support or port this business critical logic to something else. I worked at a large insurer where they slowly laid off mainframe talent over the last decade. Those mainframe salaries were counter to the narrative they were promoting arou…

> it's a management problem, and no AI tech is going to fix that. There are no absolute "management problems". Something that is a management problem when the effort required is 1000 man-years, may stop being so when it's only 100 man-days.

Given the decision would shrink a kingdom or put someone powerful out of a job it cannot be solved with AI making it easier.

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

#112

Post by hnlmorg »

JackFr wrote: post #72
vbezhenar wrote: post #44

Earlier quoted context omitted.

Language is easy, spaghetti code written without any discipline 60 years ago and modified in haste since is hard.

That is not any COBOL I’ve seen. Straightforward, well documented and comprehensively specified and tested. When we needed changes (this was back office clearing stuff for a bank) they wouldn’t even talk to us until we specced out the changes we wanted in writing and often the specs we submitted would come back with requests for clarification. This was like the opposite of agile, but I don’t recall any bugs or defect…

This was my experience too.

Modern software engineers would hate that kind of red tape because we've been conditioned to want shorter feedback loops. Heck, I hated it back then too and I wasn't even accustomed to seeing my results instantly like I am now. It takes a special kind of person to enjoy the laborious administrative overhead of writing detailed specs before you write even a single line of code.

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

#113

Post by wredue »

>it might be 80 or 90% of what they need

Yeah. Not good enough. For the life of me, I cannot remember the name, but I remember we used another IBM tool to translate cobol to Java, and what it generated was horrific dogshit Java that also was 80-90% of the way there. Thing is that, unless you have very comprehensive testing laid out (lol. Find me a mainframe shop with comprehensive testing and I’ll smash my testicles in a hydraulic press), it’s impossible to know what it missed, and thus the 80-90% of the way there was effectively 0.

We never did push forward with this tooling, but I strongly suspect that had we, the ROI would have been vastly net negative after horrendous business impacts.

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

#114

Post by wredue »

DebtDeflation wrote: post #95
hnbear wrote: post #73

Having had to support and migrate COBOL in a big financial the problems weren’t really related to the COBOL, but instead were: 1. The mainframe costs and support. These can be mitigated with migration to a platform like Microfocus to emulate it, but be careful you don’t replace your ultra reliable mainframe with some flakey Windows servers. 2. The embedded business logic. Within the 50-60 years of code there’s a ton…

>The embedded business logic. Within the 50-60 years of code there’s a ton a specific edge cases encoded for long forgotten business reasons. Honestly, this should be the top comment in the thread. The issue isn't COBOL being a hard language to learn or to translate to Java or not enough programmers or companies not being willing to pay people enough to work with it. The issue is the 50 years worth of business logic,…

>it’s if-else statements all the way down

My experience with cobol at a few companies is that you’ve forgotten the mighty GOTO.

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

#115

Post by wredue »

uxp8u61q wrote: post #79
pixl97 wrote: post #23

Earlier quoted context omitted.

I've seen some currently used COBOL that had it's like change date in the early 80s in the finance industry, so there some rather ancient programs out there. Of course this also means that these files have met the needs of the industry that long and bug free so why go messing with things that move 100s of millions/billions of dollars per day.

Even if it's not handling billions of dollars a day... Why fix what isn't broken? Software isn't an end into itself, it's a tool to solve a business need. If the business need is met, there's not anything to fix.

Because all the data and processing being on the mainframe poses loads of problems which are causing competitive disadvantages today.

As a shining example of the grief: 8 letter passwords.

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

#116

Post by janalsncm »

hobs wrote: post #111
credit_guy wrote: post #68

Earlier quoted context omitted.

> it's a management problem, and no AI tech is going to fix that. There are no absolute "management problems". Something that is a management problem when the effort required is 1000 man-years, may stop being so when it's only 100 man-days.

Given the decision would shrink a kingdom or put someone powerful out of a job it cannot be solved with AI making it easier.

That kingdom is shrinking already as people retire. Converting COBOL into Java means your kingdom can expand.

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

#117

Post by wokkel »

dun44 wrote: post #104
IshKebab wrote: post #93

Earlier quoted context omitted.

In fairness I imagine an LLM could maybe transpile to more idiomatic code. For example when you transpile FORTRAN to C you get a load of +1s and -1s everywhere to deal with FORTRAN's 1-based indexing. An LLM could avoid that. But I agree, it doesn't make sense to risk bugs just for that.

You could do it with a trivial C macro instead.

I have the pleasure of supporting a transpiled rpg (system i) to Java codebase. Shit that's come up: almost everything is a global. State machine are used for crud logic which is implicit in the rpg runtime and explicit in the Java codebase. Magic constants all over the place. Magic blobs of screen configuration mapping. Transpiling and directly supporting the transpiled codebase is basically masochism.

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

#118

Post by wokkel »

spindle wrote: post #101

I believe that practically the whole barrier to getting rid of legacy COBOL systems is testing the replacement system. Of course it's possible but it's very very expensive ... I don't have numbers for how expensive, but I've worked on financial software in COBOL on a mainframe, and nothing was the least bit abstruse or scary or difficult about it except the worry that our test suite might not be comprehensive, no mat…

No, getting a 100% equivalent working Java system is trivial. But the goal is having something that looks like it was Java from the start not Java as written by a cobol expert. So proper use of classes. Not al globals. Sensible naming etc. The real cost is in maintenance of the code: having in idiomatic Java could help. Translating to idiomatic Java is very hard

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

#119

Post by cowsandmilk »

IshKebab wrote: post #52
halfdan wrote: post #51

Earlier quoted context omitted.

You’re looking at salaries for COBOL programmers in the UK which is a small subset of an already small market.

I've checked in America before and came to the same conclusion. There's an idea that COBOL programming pays vastly more than other languages, but it's just a myth. It might pay a little more, but more like 20% more. Certainly not enough to warrant a COBOL career. And I'm sure some consultants can earn vast sums fixing old COBOL code, but that's just because they're consultants. Consultants always earn vast sums.

> Certainly not enough to warrant a COBOL career.

I don't understand why people are claiming this sets your career to only ever write COBOL. I know plenty of people who started their careers with perl, but have been Java, JavaScript, TypeScript, Go, or Rust programmers at different points as their careers progressed.

Someone overseeing a project migrating a COBOL monolith over time to a set of decoupled services in some other language would easily have a strong story for the timeless need of improving application architecture.

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

#120

Post by phasetransition »

jacquesm wrote: post #56
matthewdgreen wrote: post #25

Earlier quoted context omitted.

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.

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 ge…

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