IBM Says Its Generative AI Tool Can Convert Old COBOL Code To Java - Slashdot
source link: https://developers.slashdot.org/story/23/08/22/2037200/ibm-says-its-generative-ai-tool-can-convert-old-cobol-code-to-java
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
IBM Says Its Generative AI Tool Can Convert Old COBOL Code To Java
Become a fan of Slashdot on Facebook
binspamdupenotthebestofftopicslownewsdaystalestupid freshfunnyinsightfulinterestingmaybe offtopicflamebaittrollredundantoverrated insightfulinterestinginformativefunnyunderrated descriptive typodupeerror
Do you develop on GitHub? You can keep using GitHub but automatically sync your GitHub releases to SourceForge quickly and easily with this tool so your projects have a backup location, and get your project in front of SourceForge's nearly 30 million monthly users. It takes less than a minute. Get new users downloading your project releases today!
IBM wants to provide tooling for each step of the modernization process, starting with its Application Discovery and Delivery Intelligence (ADDI) inventory and analysis tool. Other steps include refactoring business services in COBOL, transforming the code to Java code, and then validating the resulting outcome with the aid of automated testing. The resulting Java code emitted by watsonx Code Assistant for Z will be object-oriented, but will still interoperate with the rest of the COBOL application IBM claimed, as well as with key services such as CICS, IMS, DB2, and other z/OS runtimes.
-
›
God help us the world will end.
Unless they do Cobol to Rust, in which case it will end sooner.
-
Perform.Routine.Foo.Varying(A).From(1).By(2).Until((a) -> {a <= 100};);
-
With a transition to Java it would mean that Oracle now just have to sit on their hands and collect license money for Java.
-
-
-
It would be a fun topical comment but alas even Lotus was too terrible for IBM who sold it off to HCL years ago.
-
-
Will it convert the cobwebs into classes?
-
Yay, they have an AI-assisted transpiler... will it magically figure out what code is actually valid? Figure out what the business rules are that everybody relies on but nobody knows? A lot of this old COBOL code is a pain to work with not because it is COBOL, but because it is old legacy code with little/no surviving system documentation.
I liken this to those AI scaling upscaling utilities for video. Looks great from far away, but if you look closer, it's a bunch of noise masquerading as signal that the upscaler is using with cheats to make you think it looks better.
Crap that is properly formatted and using standard modern patterns is still crap.
-
Gotta so agree with the vibe of your post and the specifics. Transmogrifying cross-compilers don't work because they aren't telepathic. At best, you might get a (probably slower) runtime or "barely works" source in another language similar to 1990's ASM decompilers (which were helpful sometimes, but no panacea). They won't give you the benefits of a well understood source tree by qualified people in a modern and effective language (like C99 or others). Magic bullets never work. They just sell meta-software.
-
The normal IBM way is to have a tool that they've been working on for years, and now rebranded it as "AI" because that's what's hype right now.
-
If it works - don't touch it.
There are things that can change behavior depending on language due to language standard that's not always caught by translation programs.
-
-
Brilliant move on the part of IBM. Forcing a rogue AI to read, write, or (worst) run COBOL for any purpose should be as sure-fire a way to drive them to suicide as Making. Them. Listen. To. William. Shatner's. Unique. Perspective. And. Diction.
-
Corbomite Maneuver.
-
-
Given the likely use cases for all this still-in-production legacy COBOL, a human with the know-how really really REALLY needs to thoroughly review and test the translated Java code before it's deployed. I realize IBM claims their "AI" will also do the testing, but relying on that would be incredibly stupid.
On the other hand - if one of the big banks uses IBM's tool, and unknown errors in the final code result in that big bank losing billions of dollars... IBM could get sued out of existence. So maybe that'd be a win overall?
-
the fractions of a Penny will rounded off
-
⦠into an account that we open.
-
-
The human with the know-how retired in 1988. That's why it is still running in COBOL on a z mainframe.
-
It's secretly just an emulator that mimics an S-370 so that the code runs natively just fine. The java thing just sits there and reminds the computer operator how clever IBM is to figure out how to make the stuff work that they already made work 60 years ago.
-
I doubt that the translated code would ever make it to production. IBM's consulting group is filled with "experts" at stretching out doomed projects for years and collecting millions in consulting fees in the process.
-
-
If they integrate formal verification that the new code will perform the same as the old code then this will be a real winner. Without formal verification only the desperate will use it.
-
Even if it can be proven to work, it's replacing hand written code with machine generated blech. If it ain't fun to maintain now, good Jebus.
-
> If they integrate formal verification that the new code will perform the same as the old code then this will be a real winner
Some time ago, looking at a piece of code used to deliver real time stock quotes to bank customers, I found the comment "This works, but I don't know why". I bet it would not pass formal verification...but, for what I could check, it worked! -
Without formal verification only the desperate will use it.
Turns out banks are desperate to make a profit.
No fuckwit [wikipedia.org] would trash the IT systems in a bank [theguardian.com] to hike profits before bailing would he?
-
-
This approach feels backward. COBOL is well known to be stable, easy to read, and relatively easy for newcomers to pick up. Java is relatively complex (in terms of syntax and structure), has had a questionable ecosystem and future in recent years, and it's relatively hard to read someone else's Java code. Translating COBOL to Java just seems to be making everything harder for everyone involved - unless the company is entirely unable to find/hire COBOL developers.
I'd rather see tools that go the other way and translate server-side Java code to COBOL.
-
I don't know. I have tried to read some COBOL to support old software and it is nearly assembly language and extremely tedious.
-
Wishful thinking there, bud. Java is the most uniform language I've ever seen. The coding style was set in 1997 and most apps written by decent developers rely on frameworks that are 10-20 years old. It's dull, uniform code. There's little variance in the code written in the last 10 years and that's actually a good thing. If you can't read someone else's Java, you either work with some real maniacs or the problem is you...try looking at open source...if you still can't read the major libraries...the pr
-
mmm but
You're comparing Java to C/C++/Javascript/Python/etc/etc, the OP is comparing it to COBOL.
I don't really have a horse in this race: I've used Java but not very much, and only in weird, not very idiomatic contexts. I don't hate the language (I've gone off the idea of hating languages) and if anything the language was indeed simple and boring (good if one doesn't have much experience) with the complexity all being in the systems I was interfacing to. I've never seen COBOL code in the wild though.
-
-
-
A generative AI that can port OS/2 applications to Windows 3.11 for Workgroups?
-
Translating old, crappy code into java is not the answer
We need an AI tool that analyzes the code, figures out what it does, and helps us remove bugs and clean it up
The problem with old COBOL code is not the language, it's the unstructured way it was written and modified over many years-
sounds like you have first hand experience with COBOL. I've seen mainframes apps in healthcare and the piles of ugly COBOL is deep and messy. I've forgotten how many times we were told "it does this" and we find out "nope it does something different."
then we spend a bunch of time documenting what it actually does and working around the issues we find.
-
-
What does IBM do nowadays anyway? I see ads occasionally, but they are so vague I really have no idea.
At least this is kind of specific. Although it is hard to believe it will actually work. I mean, what I am seeing from LLMs does not instill confidence. The problem is that the errors introduced by LLMs are hard to spot because above all else, LLM output always looks plausible. Even when it is wrong. So you have to proofread it carefully or you will just nod and go "yeah, yeah."
Maybe IBM's generative AI for producing code will not work this way.
-
I can even believe that the code will do what it is supposed to do.
What I have a hard time believing is that the code will be worth a crap, or that it will actually wind up cheaper than just sending some good programmers to cobol classes.
-
Nobody still running COBOL in production is going to trust your AI LLM for jack sh*t.
-
Scrolling down, your comment comes closest to what I was thinking.
COBOL in production is there because they're afraid that if they look at it the wrong way, it'll destroy their business. I picture these being the kinds of places where you propose to change a few lines, and it goes through a multi-week review process, then a multi-week test run, then a very nerve wracking roll-out phase that's almost but not quite guaranteed to prevent some guy in a white shirt with a pocket protector from jumping out a win
-
Yeah but their manager's manager's manager's manager's director's VP's C-suite boss think it's a really clever way to save enough money and get a sweet performance bonus this quarter?
-
-
As someone who worked on a project which ported COBOL from IBM mainframe to Solaris systems (long ago), the code was the least of our problems. The killer issue was the SQL in that code, that wasn't fully compatible between the mainframe version of IBM DB2 and the UDB DB2 which ran on Unix. In fact, nearly every module of that code took advantage of certain "features" of mainframe DB2 that just were never going to be available in another database.
-
What is the size of the mountain of punched card chad equivalent to 850 billion lines of COBOL? That's over 100 lines of code for each living person on the planet.
-
When I was lecturing on software engineering back in the late 1980s, I regularly used to cite the latest figures for the amount of COBOL out there. It was about 200 billion lines. Later, in about 1995, I noticed that it was now being quoted as over 300 billion.
And today it's in the region of 850 billion?
What does this tell us?
-
-
Why do I not find this type of translation remarkable, given the input and output?
-
Coverts code in seconds via AI only takes a 6-12 more months to troubleshoot via human.
-
You may laugh, but MANY years ago, I was working at IBM on some code that processed checks. It was written in an IBM internal language (PL/X), that ran on OS/2 and Linux. There was no PL/X compiler for the desired target machine (Linux on system/z). I found some old IBM software called PLX-ETC. PL/X would spit out assembler for the target. But PLX-ETC would spit out "C" that you could compile on the desired platform. PLX-ETC had extra switches for instance big/little endian and many others. It actual
-
I'm more interested in an AI to convert Java to COBOL, because I have an old System 360 in my attic and I want to run my empire using that trustworthy technology. And I have a full 10 MB drive in my basement (because it weighs 500 pounds). Gosh those were the days. I plan to enclose my kitchen in glass and airconditioning, and use it as the command center.
You - don't wave your phone at me and laugh! You kids get off my lawn.
-
COBOL is a local optimum for the tasks at hand. Yes, code grown over the last decades is terrible, but it's not like new Java programs are necessarily better. The abstractions found in Java are not necessarily better for business calculations.
Also there is the whole problem of actually running the code. While COBOL compilers probably will be around in many decades, the future of Java is much less certain.
Then there is of course the issue of automatic code translation. Yes that can be done, even without "AI"
-
the future of Java is much less certain.
Not for this stuff: IBM have their own Java implementation. They can keep it going forever.
-
-
Is the AI going to be smart enough to understand the ancient spaghetti code written by long-retired or dead programmers in the 1960's and 1970's? Is what is generated going to be any more comprehensible than the original? There are reasons why some ancient programs are never touched for any reason. No one now employed by these companies understands or could understand how they work because they are so cryptic and convoluted and no one dares make any modifications. It seems that this AI will just make a
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK