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…
Watsonx: IBM's code assistant for turning COBOL into Java
171–180 of 186 posts
Re: Watsonx: IBM's code assistant for turning COBOL into Java
#172Earlier 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.
Re: Watsonx: IBM's code assistant for turning COBOL into Java
#173Earlier 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?
Re: Watsonx: IBM's code assistant for turning COBOL into Java
#174The 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.
* 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
#175Earlier 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.
Re: Watsonx: IBM's code assistant for turning COBOL into Java
#176Re: Watsonx: IBM's code assistant for turning COBOL into Java
#177Earlier 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…
Re: Watsonx: IBM's code assistant for turning COBOL into Java
#178Regarding 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…
Re: Watsonx: IBM's code assistant for turning COBOL into Java
#179Earlier 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.
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
#180Earlier 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…
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 & $)