Live data from Hacker News

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

pcmag.com

171–180 of 186 posts

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

#171
post #109

Earlier quoted context omitted.

Why would software technology ever stop moving? To a first approximation it is unconstrained by physical reality (unlike other engineering disciplines) so I expect it will keep moving at roughly the same rate. Maybe even accelerate in some areas. Individual organizations can consciously choose to slow down. Which works for a while in terms of boosting quality and productivity. But over the long run they inevitably fa…

Software technology moves when we figure out new ways of doing software that bring some kind of advantage. If no one is finding new ways to do software that have any purpose, technology will stop moving. Physical reality doesn't really have anything to do with it - we're limited by human ingenuity, and possibly by the mathematical space of algorithms (though that's likely to be much larger). For an example of this ha…

Software trends seems to repeat themselves as we forget the lessons learned a decade ago. It’s more like fashion, in that sense.

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

#172

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.

You don't need better programmers to maintain a js project, you only need hireable programmers.

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

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

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?

Kind of the later I guess. Not much migrated really. When I left they were grappling with which major migration to do next, each to the tune of tens of millions each with no business benefit. In that industry there is momentum toward specialty tech platforms to save the day. Out of the frying pan into the fryer.

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

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

I'm pretty sure there's already a system to transpile COBOL to Java without resorting to LLMs.

I was thinking the same. It looks to me like a much safer process could be:

* use some kind of deterministic transpilation that creates ugly code which for sure reproduces the same behaviors

* add tests to cover all those behaviors

* refactor the ugly code

From my experience with copilot I guess that a LLM could help a lot with steps 2 and 3, but I wouldn't trust it at all for step 1

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

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

I’m not convinced the proposed solution is that. This pitch has been around for a long time, before LLM it was some unnamed proprietary technology and after LLM it’ll be something new. The reality is this stuff is hard even when 80% can be automatically converted.

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

#176
I want to go back to doiyng COBOL programing, so that I can land a job to keep a system up to date. However, while learning COBOL is not that complicated, learning the mainframe part is, because it is very difficult to find a mainfrane to work on, and I have not yet found an emulator to learn on it.

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

#177

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…

If there was an HN equivalent of Reddit's /r/bestof, this comment would deserve to be there. Encapsulates everything about why this problem is so hard.

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

#178
post #6

Regarding IBM's use of technology widely known for hallucinating to translate sensitive source code: it sounds weird you think the primary objective here is to deliver something that properly translates from one language to another. But it is not - the primary objective is to get money from customers and investors. Delivering something that works is secondary, and honestly, optional. Many things in IT start making a…

Indeed. If you are the board of any publicly traded technology company right now, and you don't have an AI strategy that you are telling the market, your stock is going to take a beating as investors flock to those who do. The strategy doesnt need to have a lot of meat behind it. Once it was crypto, now its AI, tomorrow it'll be something else. But AI has really captured people's imaginations, which means even the most foggy investors are looking at it. That drives leadership behavior more than the tech itself

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

#179

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.

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.

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.

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

#180

Earlier quoted context omitted.

How do you like the job? (Just curious, no relation with or friends at IBM.)

Like many large companies, IBM discourages us from engaging in "social media" (which I guess includes HN) on work-related questions. I felt that I could make an exception for the minor correction of the product name. It's probably not appropriate for me to comment here on how I like the job. I would be happy to discuss it privately with you or anyone else who is curious. My email address is in my profile; feel free t…

not op

appreciate the comment

this exchange is what i show young people to demonstrate why you should never work for such companies (not signaling out yours specifically)

human want to be human

(tho a buddy of mine worked there with great benefits & $)

Post reply on HN