IBM Says Its Generative AI Tool Can Convert Old COBOL Code To Java (theregister.com) 108
IBM is introducing the watsonx Code Assistant for Z, a tool that uses generative AI to translate COBOL code to Java. This tool is set to be available in Q4 2023 and aims to speed up the translation of COBOL to Java on IBM's Z mainframes. The Register reports: According to IBM, there are billions of lines of COBOL code out there as potential candidates for modernization (a report last year estimated the total figure at 775-850 billion lines). For this reason, the generative AI features in watsonx Code Assistant for Z are intended to help developers to assess and determine the code most in need of modernization, allowing them to more speedily update large applications and focus on critical tasks.
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.
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.
oh dear (Score:5, Funny)
God help us the world will end.
Unless they do Cobol to Rust, in which case it will end sooner.
Re: (Score:3)
Re: (Score:1)
With a transition to Java it would mean that Oracle now just have to sit on their hands and collect license money for Java.
Re: (Score:3)
Pull your money from the banks and you should be safe, lol
Re: (Score:2)
God help us the world will end.
Unless they do Cobol to Rust, in which case it will end sooner.
The world will CALL "ABEND" you mean.
Re: (Score:2)
Lotus Notes java now with 4G more ram used! (Score:5, Funny)
Lotus Notes java now with 4G more ram used!
Re: Lotus Notes java now with 4G more ram used! (Score:2)
It would be a fun topical comment but alas even Lotus was too terrible for IBM who sold it off to HCL years ago.
Re: (Score:3)
"Lotus was too terrible for IBM who sold it off to HCL years ago."
How appropriate. I always thought Lotus Notes needed to be dissolved in acid.
COBOL to Java? (Score:3)
Garbage in, garbage out (Score:5, Insightful)
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.
Re:Garbage in, garbage out (Score:4, Insightful)
Re: (Score:3)
Yay, they have an AI-assisted transpiler... will it magically figure out what code is actually valid?
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.
Re: (Score:3)
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.
Re:Garbage in, garbage out (Score:5, Funny)
COBOL has dialects, most of the language is defined by the specs but some parts are implementer-defined. To make it more entertaining, some language features have moved from "core feature" to "implementer defined" - and vice versa - over the years, new core features are sometimes at variance with the way previous compilers handled things.
Taking a number at random, let's say the 1999 standard (I made that up) breaks some of the extensions the implementer added to their 1968-standard compiler (I have seen this). The new compiler can be incompatible with the old one (1), it can have a "compatibility mode" (2) or it can continue doing things the old way (3). The compilers I used tended to go for a mixture, mostly of (1) and (2) but maybe with a whiff of (3) mixed in. What I saw with Fortran under similar circumstances was a "convert" option, on the whole it was reliable.
I take it that this translation program can handle one or more specific implementations, presumably of IBM compilers.
COBOL is a byte-orientated language, although some things (parameters in subroutine calls) had to be word-aligned. Sometimes programmers screwed up there, assembler subroutines could maybe notice and either compensate or abort on the spot (if it's wrong on one call it's going to be wrong the next time you go through that code as well). I have no idea how that maps to Java, does Java even offer all of the data types COBOL does? I'm talking mostly about the various representations of numerics.
About the worst program I ever saw allowed a subscript on a particular table to take values - such as zero - outside the range of the table. Someone had added comments there to the effect of "this is the beginning of the disaster zone" and "this is the end of the disaster zone". This was years ago but I think the programmer had been moved on before I ever got to see that monstrosity.
Re: (Score:2)
Strictly speaking now.
At least not as a byte for byte mapping.
Re:Garbage in, garbage out (Score:4, Insightful)
Yup. What if the java code doesn't perform exactly like the COBOL code? Who's going to search for the hidden bug in the AI generated code? Will they wait till the next AI generation to do that?
Re: (Score:1)
If the COBOL code was not used in production, why transpile it?
And transpiling only means you transform code from one language into another, has not really anything to do with "working" or not.
So "garbage in garbage out" is exactly what one would expect.
Anyway, anayone has an idea what happend to the COBOL to java byte code compilers?
So that's how we can Kirk those AIs! (Score:5, Funny)
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.
Re: (Score:3)
Corbomite Maneuver.
Re: (Score:3)
We still have stuff at work in EGL/VG which was IBM's (then sold off) attempt at having a single language that could then generate to COBOL or Java.
The Java code it generates works, but is unmaintainable and very very ugly and looks nothing like what a human would do for equivalent code in Java.
Okay, great... but (Score:5, Interesting)
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 (Score:5, Funny)
the fractions of a Penny will rounded off
Re: the fractions of a Penny will rounded off (Score:1)
Re:Okay, great... but (Score:5, Insightful)
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
This would be great IF... (Score:5, Insightful)
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.
Re: This would be great IF... (Score:3)
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.
Re: (Score:2)
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!
Re: (Score:2)
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?
Re: (Score:2)
As formal verification cannot be automatized (it has been tried for 50 years or so), and requires a lot of work by really expensive experts, that is not going to happen.
Re: (Score:2)
formal verification cannot be automatized
Well, you're wrong about that: https://compcert.org/ [compcert.org]
Re: (Score:2)
Nope. You just do not understand what you are talking about. Your reference is about something else.
Re: (Score:2)
https://en.wikipedia.org/wiki/... [wikipedia.org]
In the context of hardware and software systems, formal verification is the act of proving or disproving the correctness of intended algorithms underlying a system with respect to a certain formal specification or property, using formal methods of mathematics.[1]
Re: (Score:2)
You still do not understand what you are talking about. Verifying the compiler verifies the compiler, not the code it compiles. That code is just as correct or incorrect as was before compilation. All that verifying the compiler does is prove the compiler (within the assumptions it was verified under, which are always pretty restrictive for compilers) does not add faults.
As to how the compiler was verified, that is usually done by a human expert guiding a specialized proof verifier through the proofs. Proof
Re: (Score:2)
Verifying the compiler verifies the compiler, not the code it compiles.
No, it checks each step of compilation, verifying that the resulting generated code matches it's source. It's also capable of compiling itself thereby ensuring it's a formally verified compiler. You stated that "formal verification cannot be automatized" and I showed you a compiler that does that.
You seem to be quite ignorant on the topic of automated formal verification. Please come back after doing some research.
Re: (Score:2)
Nope. This does not automatize the verification. And nope, verifying the compiler just assures it compiles correctly (within some usually rather gross limitations). It does not verify the code compiled in any way (including the compiler itself, assuming it can self-compile). The verification for the compiler was done _before_ on source code level, and by other means. That means the code a verified compiler produces is _not_ verified to be correct in any way. It just is functionally equivalent (within some r
Re:This would be great IF... (Score:4, Informative)
I expect that once the conversion is complete and cursory checks pass the original Cobol source will become lost or get deleted. Then when a bug or corner case is found no one will know how it is supposed to work and have nothing to fall back on.
Re: This would be great IF... (Score:2)
Because countless major corporations rely on COBOL written decades ago and were never documented or tested? The COBOL industry existed likely before your father was born, they somehow figured out RAID and VMs before you were even a twinkle in your mother's eye.
Re: This would be great IF... (Score:2)
Now, get off my lawn!
C'est what? (Score:1)
Re: C'est what? (Score:2)
Why not COBOL to Python? Or Scratch!
Re: (Score:2)
Feels backward (Score:4, Interesting)
Re: (Score:2)
You've clearly never worked with Java (Score:5, Insightful)
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.
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 problem exists between keyboard and chair. I read Java all the time from contributors in about 100 countries. I have no problem figuring out what they're doing and I've never met them and never even know much about the projects they're working on. Most projects are under-documented, but it's still far easier than most of the JavaScript and Python code I've had to read. I can always figure out "what" they're doing...the "why" they did it that way is always the part I have the most difficulty with (specifically what was the business rationale for their decisions).
Looking at C++, JavaScript, C, Python, and even the languages of the past, such as Groovy, Ruby, PHP, and ColdFusion, Java is the most uniform, by far. In fact, most complain because it is so uniform and conventional and does every field really need a getter and setter? Nearly all Java looks alike and many of us think that people should think more independently question the ceremony many Java apps have.
Look, you don't like Java, that's cool...some have good reasons, given your post above, I will wager you don't and simply don't know much about programming. If Java "makes everything harder" than COBOL, you're either disingenuous, really peculiar, or uninformed.
Re: (Score:2)
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.
Re: (Score:1)
The same thing could obviously be said about you.
As you obviously know nothing at all about COBOL and how "records" in Cobol work.
Good luck to even remotely model or write Java code that mimics that.
Then why did the industry abaondon it so quickly? (Score:2)
The same thing could obviously be said about you. As you obviously know nothing at all about COBOL and how "records" in Cobol work.
Good luck to even remotely model or write Java code that mimics that.
I don't need to know how COBOL records work. #1, I don't care if superior technology exists. I am a professional and go where the money is. The money is not in COBOL at the moment. Yeah, a few consultants get to charge high hourly rates to maintain nightmare abandoned codebases, but it's not sustainable and I know a few programmers that do this and they complain about it all day. My employer invests in code to make money and thus treats us nicely. The COBOL shops consider it a legacy expense and nuisa
Re: (Score:2)
What? Ruby and PHP didn't ever go after Java's bread and butter. PHP competed primarily with Perl CGI and various other server-parsed web page systems. Ruby tried to compete with Python as the dynamic language for everyone. C# and Go are Java's biggest competitors, with Rust also trying to muscle in on its space.
Re: (Score:2)
PHP tried to take away the lower end of the market and from what I can tell, it's gone.
Um ... php is the towering dominator language of the web. (And therefore also of lots of glue code that interfaces with the web.) Java has definitely receded in that space vs. php.
Re:Feels backward (Score:4, Funny)
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.
But it will increase employment for huge teams of foreign programmers, so it's not all bad ...
Re: (Score:1)
Java literally runs everywhere. Cobol not so much. ...
But who needs a Cobol "app" on an Android tablet
Re: Feels backward (Score:2)
Where doesn't COBOL run? Granted, its primarialy runs on mainframes, but I've seen COBOL run on TRS-80s, CP/M machines, Unix/Linux, Windows, and countless "business minicomputers" (Prime, Basic Four, OSI, Data General, DEC, etc). Hell, I bet I could run COBOL on a RPi with little effort.
BUT, saying COBOL typically is a placeholder for a list of tools that go with code written in COBOL running in mainframe computers using CICS, IMS/DB, DB2, and others - those tools are (last I looked), largely, but not exclu
What's next, IBM? (Score:3)
A generative AI that can port OS/2 applications to Windows 3.11 for Workgroups?
Wrong approach (Score:3)
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
Re: (Score:1)
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.
Re: (Score:2)
Agreed.
Unit testing was not a well-known discipline back when most of this ancient old COBOL was written.
However, really good unit tests with complete code coverage would likely yield enough knowledge of what the code does, to be able to refactor it, and/or to port it to another language.
That still does not usually answer the question of why. And not knowing that can be really frustrating, can lead to edge or corner case bugs when the code is modified, etc., but, even in COBOL, unit testing should em
Re: (Score:2)
The problem with old COBOL code is not the language, it's the unstructured way it was written and modified over many years
Old COBOL programmer here, this cannot be said enough. I got into COBOL programming late in the game, and to the amazement of my coworkers successfully applied structured programming techniques.The existing code I worked with was somewhere on the spectrum from bad to unintelligible. Its authors just didn't know any better, many of them applying techniques they'd learned writing assembly language for the IBM 1401. GOTO DEPENDING ON anyone? Heck, there was even a widely used tool that converted 1401 assembler
Re: (Score:2)
I got into COBOL programming late in the game, and to the amazement of my coworkers successfully applied structured programming techniques.
I want to emphasize this point because I have done the same thing. I wrote FoxPro and Tcl code in a structured way, when my predecessors were not doing so. They were impressed at how readable the resulting code was. While some languages do lend themselves better to structured programming, I find that often the programmer culture is the limitation, not the capabilities of the language.
What does IBM do nowadays? (Score:3)
Re: (Score:2)
What does IBM do nowadays anyway?
Same thing they've been doing since the early 90s: Buy technologies that are interesting to their big corporate clients (IBM's definition of a "small business" includes annual revenues of at least $4B), package them together with other related technologies, plus bits of IBM's own tech, build services offerings to integrate the bundles into corporate infrastructure and then use their world-beating network of salespeople and sales engineers (yes, that's a thing) which are tightly embedded into basically every
Re: (Score:2)
That explains why the ads are kind of vague.
I have probably never worked for a company big enough to be a small business by that standard. Anyway thanks for answering!
I can believe it (Score:2)
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.
Understanding your target market (Score:2)
Nobody still running COBOL in production is going to trust your AI LLM for jack sh*t.
Re: (Score:2)
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
Re: (Score:2)
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?
What's the point? (Score:2)
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.
Dinosaur to dinosaur conversion (Score:2)
By a dinosaur.
Angle of repose (Score:2)
Re: (Score:2)
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?
Re: (Score:3)
What does this tell us?
That dinosaurs are still fertile and can reproduce?
Re: Angle of repose (Score:2)
That COBOL code follows Moore's Law?
Funny thing is, translate program is 'cat' (Score:2)
Why do I not find this type of translation remarkable, given the input and output?
Super useful (Score:2)
Translation. (Score:1)
Re: (Score:2)
We never released anything from PLX-ETC.
Why, by the way? Was the assembler code generated by the PL/X compiler more readable than the C code generated by PLX-ETC?
Maybe the goal of PLX-ETC wasn't to generate readable/modifiable/vettable C code. Maybe its goal was just to make PL/X code universally runnable, piggybacking on C?
Re: (Score:1)
don't stop there (Score:2)
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.
Re: (Score:2)
Convert Java code to RPG and then you might be able to adapt it to run on an IBM 407 accounting machine.
But why? (Score:2)
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"
Re: (Score:2)
the future of Java is much less certain.
Not for this stuff: IBM have their own Java implementation. They can keep it going forever.
Spaghetti code (Score:3)
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 bad situation worse!
Also, this AI by IBM seems to be a cross-purposes with one of the reasons why companies continue to buy IBM mainframes: They are binary and software compatible with mainframes and operating systems developed nearly 60 years ago and require no modification or recompilation. Java programs, on the other hand, can be run literally anywhere in cyberspace. Sure, IBM mainframes are about as close to 100% reliable as you can realistically get, but cloud computing is less expensive.
Why use AI? (Score:2)
AFAIK, there are Fortran-to-C translators and other language-to-language translators too, which work properly, yet they don't use generative AI. What added value can the generative AI provide in this case? Better publicity?
Re: (Score:2)
Better publicity?
Probably. Using a non-deterministic, unpredictable and unreliable mechanism to translate code is pretty much the pinnacle of stupidity though.
COBOL/AI Have Same Goal: Get Rid of Programmers (Score:2)
Interesting idea (Score:2)
But I wouldn't use AI. At least, not as the sole or even primary component.
It would be easier to convert the COBOL code to a formal specification and then convert the formal specification into Java (or, better, Rust).
Easier because you could be certain that the end program did the same as the start program if you did it that way (so long as the specification was derived and then reified correctly), whereas with AI, you'd have an indeterminate deviation from the original code and you've no obvious way of det
You may even get a bit extra! (Score:2)
"Functionality", that is when the AI hallucinates some extra code.
Why Java? (Score:2)
Re: (Score:2)
Java appeals to the same sort of conservative and risk-averse mindset* that produced the original COBOL (as one of its appeals among many). It's boring, stable, predictable, everyone knows it or something like it, it can in theory be offshored, it is not subject to continuous churn, it offers a very low TCO if done right, etc., etc., etc.
From a purely technical standpoint, modern C# improves on Java in almost every way. However, I would concede that it is a tad less stable in the ways that concern top ma
Oh Look! (Score:1)
Re: (Score:2)
That would have been my expectation until recently.
But yesterday I took a block of parsing code written quickly in fairly idiomatic C# and asked ChatGPT to translate it into Python. I was not expecting great results. I just wanted to see what would happen, and hoped for something I could then massage into a fully working program.
What it made was not optimally Pythonic, and closer to a word-for-word rather than idea-for-idea translation of the code.
But it worked perfectly exactly as it came out, producing
haha. good one. (Score:2)
Just wondering, who is going to debug the java?
Will Watson also be acting as lawyer (Score:2)
I don't know why anyone willingly writes in Java anymore. You're literally begging Oracle to come sue you for some compliance trap you'll inevitably fall into.
(Go ahead and mark this as a troll post, but deep down you know it's true.)
Comment translation as well? (Score:2)
That's all fine and good.
But how will the person feeding the old code to the A.I. explain the point of the business process (without writing more code)?
Will this A.I. also translate all of the comments? Indeed, can explain the context behind all of the nuances in a references in code comments to a long-dead CIO's peccadillos, or the quote of programmer's favorite novel/movie/song, when it explains the function of the code?
(Because I've seen all of that in code that's just ten years old, forget about code th
Where to start.... (Score:2)
I suppose that as a "look at we can do with AI" type of exercise, it is impressive. But in practical terms, I question who is ever going to use this?
COBOL has been around, basically forever, for one simple reason - it works. It tends to be wrapped around critical business processes - like payroll, banking, insurance. It is really good at processing huge volumes of data very quickly and reliably. Unfortunately, a lot of that ancient code was not well documented and a lot of those programmers are long gone. S
Re: (Score:2)
Wishful thinking, buddy. Especially about Java, C++ and even Fortran. Well, TBH, it might happen, 30 years from now, but don't hold your breath.
Re: (Score:2)
Dear Lord. Where do I start.
OK, Perl to Python for new code makes sense.
But Java is FAR from dead. It may well have more LOC in production right now than anything except COBOL. Also, none of your proposed replacements plays in the same space. Mostly, if you want to do Java without doing Java (because, say, Oracle) you'd use C# on .NET Core.
C++ is likewise far from dead. Newer projects might choose Rust for its memory safety improvements. Network-centric systems also might choose Go. But again neither