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

141–150 of 186 posts

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

#141

Post by bradleyjg »

jacquesm wrote: post #129
wongarsu wrote: post #126

Earlier quoted context omitted.

> if you start a bank today you'd do the whole cycle all over again It is worth noting that we now have much better processes and tooling than software developers had in the 60s. Some Cobol systems predate the invention of SQL or database normalization (3NF, BCNF, etc). Never mind the prevalence of unit testing and integration testing, automating those tests in CI, the idea of code coverage and the tooling to measure…

We have better processes but we don't necessarily have better programmers, and better tooling is no substitute for that.

We have significantly worse programmers, that’s what better languages and better processes enable. People that would have washed out when the only option was bit twiddling and pointer chasing can now be productive and add value. That’s what progress looks like.

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

#142

Post by haolez »

girvo wrote: post #139
rcbdev wrote: post #131

Earlier quoted context omitted.

During my time at the company we never once talked about what the customer actually needed or wanted. Your story confirms my suspicion that this type of sales-driven development is just how IBM operates anywhere. The truth is, IBM has been bean counted to death. Their turnover rates are incredibly high, employees have to deal with utilization targets that they can't meaningfully do anything about and lines of communi…

And the R&D guys at IBM are 1) brilliant and 2) smart enough to stay well away from IBM proper as much as they can, at least when I partnered with some, some years ago

The best engineer that I know worked a long time for IBM. Until he couldn't bear with it anymore.

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

#143

Post by GenerWork »

rubyfan wrote: post #58
ufmace wrote: post #21

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

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

Did the remaining mainframers demand a higher salary to stay on, or did the insurance company have to hire outside contractors at exorbiant rates to migrate everything over?

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

#144

Post by aitchnyu »

buro9 wrote: post #30

https://www.glassdoor.co.uk/Salaries/cobol-programmer-salary... If it's so valuable to the industry that they have good people who know it, that should surely be reflected in the salary / comp for roles... And if that were high, people would learn it, but it's not high, it's arguably worse than just learning a little JavaScript

Indian companies take fresh graduates and train them into mainframe devs. I was a little sceptical about shrinking pool of highly paid people.

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

#145

Post by dzhiurgis »

kolinko wrote: post #124
ufmace wrote: post #21

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

As far as I understand, the issue with Cobol specifically is that the code is riddled with gotos and global variables - and untangling all that mess is the real issue, not converting into Java itself. Using traditional algorithms you end up with literal exponential complexity very fast. You also need a human's ability to figure out which new abstractions to create - otherwise you will end up with a code that is just…

Isn’t global variables at some point a requirement for performance? Or is there patterns that can do both?

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

#146

Post by [deleted] »

dzhiurgis wrote: post #145
kolinko wrote: post #124

Earlier quoted context omitted.

As far as I understand, the issue with Cobol specifically is that the code is riddled with gotos and global variables - and untangling all that mess is the real issue, not converting into Java itself. Using traditional algorithms you end up with literal exponential complexity very fast. You also need a human's ability to figure out which new abstractions to create - otherwise you will end up with a code that is just…

Isn’t global variables at some point a requirement for performance? Or is there patterns that can do both?

[deleted]

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

#147

Post by vardump »

dzhiurgis wrote: post #145
kolinko wrote: post #124

Earlier quoted context omitted.

As far as I understand, the issue with Cobol specifically is that the code is riddled with gotos and global variables - and untangling all that mess is the real issue, not converting into Java itself. Using traditional algorithms you end up with literal exponential complexity very fast. You also need a human's ability to figure out which new abstractions to create - otherwise you will end up with a code that is just…

Isn’t global variables at some point a requirement for performance? Or is there patterns that can do both?

Global variables usually hinder performance on modern hardware. Harder to use multithreading and (sometimes) higher probability for false sharing.

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

#148

Post by StillBored »

kochbeck wrote: post #94
the_only_law wrote: post #27

Earlier quoted context omitted.

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.

It’s not that the mainframe is hard to learn. In fact, the environment is pretty easy to understand once you get past the archaic naming (but let’s not kid ourselves: on the POSIX side we’re still running t[ape]ar[chive] and other archaic tools too). In a way, the ease IS the problem: the runtime environment for COBOL (and other stuff on the mainframe) assumes that the underlying platform and OS deal with the really…

100% agree, but AFAIK the HW isn't doing lockstep on modern zseries. The nonstop was also HW lockstep many years ago and they converted to a checkpoint restart model, which AFAIK is the same on zos/etc with help from the "HW" which is just "software" running in the LPAR/etc.

Regardless, there have been various clustering/SSI/etc software layers designed to make windows/linux/etc behave as though it were lock stepped as well via software/hypervisor checkpoint restart.

So it is not impossible, but you don't get it out of the box because most of these applications have moved the fault tolerance into an application + database transactional model where the higher level operations aren't completed until there is a positive acknowledgment that a transaction is committed (and the DB configured for replication, logging, whatever if needed, blocks the commit until its done).

So, yes that model requires more cognitive overhead for the developer than Cobol batch jobs, which tend to be individually straightforward (or the ones i've seen the complexity is how they interact). But the results can be the same without all the fancy HW/OS layers if the DB is clustered/etc.

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

#149

Post by sublinear »

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.

Management problems have a tendency to snowball and land on the next manager.

Higher authority doesn't understand it and the subjects don't care.

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

#150

Post by girvo »

haolez wrote: post #142
girvo wrote: post #139

Earlier quoted context omitted.

And the R&D guys at IBM are 1) brilliant and 2) smart enough to stay well away from IBM proper as much as they can, at least when I partnered with some, some years ago

The best engineer that I know worked a long time for IBM. Until he couldn't bear with it anymore.

I haven't checked, but I would not be surprised if the engineers I'm talking about have left too at this point. I worked on a homomorphic encryption system for some insurance companies to be able to query each others claim data with them, fun project!
Post reply on HN