Can IBM's Watson Translate the World's 60-Year-Old Cobol Code? (pcmag.com) 120
"Every day, 3 trillion dollars worth of transactions are handled by a 64-year-old programming language that hardly anybody knows anymore," writes PC Magazine. But most school's don't teach the mainframe programming language COBOL any more, and "COBOL cowboys" are aging out of the workforce, with replacements in short supply.
"This is precisely the kind of problem that IBM thinks it can fix with AI." IBM's approach is fairly straightforward: Rather than relying exclusively on a limited pool of human programmers to solve the problem, it built a generative AI-powered code assistant (watsonx) that helps convert all that dusty old COBOL code to a more modern language, thereby saving coders countless hours of reprogramming. In extremely simplified terms, the process is similar to feeding an essay written in English into ChatGPT and asking it to translate certain paragraphs into Esperanto. It allows programmers to take a chunk of COBOL and enlist watsonx to transform it into Java.
But of course, it's not quite that simple in practice... After IBM and the customer have a thorough understanding of the application landscape, the data flow, and the existing dependencies, "we help them refactor their applications," says IBM's Vice President of Product Management, IT Automation, Keri Olson. "That is, breaking it down into smaller pieces, which the customer can selectively choose, at that point, to do the modernization from COBOL to Java." Skyla Loomis, IBM's Vice President of IBM Z Software adds, "But you have to remember that this is a developer assistant tool. It's AI assisted, but it still requires the developer. So yes, the developer is involved with the tooling and helping the customers select the services."
Once the partnership between man and machine is established, the AI steps in and says, 'Okay, I want to transform this portion of code. The developer may still need to perform some minor editing of the code that the AI provides, Loomis explains. "It might be 80 or 90 percent of what they need, but it still requires a couple of changes. It's a productivity enhancement — not a developer replacement type of activity."
The article quotes a skeptical Gartner Distinguished Vice President and Analyst, who notes that IBM "has no case studies, at this time, to validate its claims."
"This is precisely the kind of problem that IBM thinks it can fix with AI." IBM's approach is fairly straightforward: Rather than relying exclusively on a limited pool of human programmers to solve the problem, it built a generative AI-powered code assistant (watsonx) that helps convert all that dusty old COBOL code to a more modern language, thereby saving coders countless hours of reprogramming. In extremely simplified terms, the process is similar to feeding an essay written in English into ChatGPT and asking it to translate certain paragraphs into Esperanto. It allows programmers to take a chunk of COBOL and enlist watsonx to transform it into Java.
But of course, it's not quite that simple in practice... After IBM and the customer have a thorough understanding of the application landscape, the data flow, and the existing dependencies, "we help them refactor their applications," says IBM's Vice President of Product Management, IT Automation, Keri Olson. "That is, breaking it down into smaller pieces, which the customer can selectively choose, at that point, to do the modernization from COBOL to Java." Skyla Loomis, IBM's Vice President of IBM Z Software adds, "But you have to remember that this is a developer assistant tool. It's AI assisted, but it still requires the developer. So yes, the developer is involved with the tooling and helping the customers select the services."
Once the partnership between man and machine is established, the AI steps in and says, 'Okay, I want to transform this portion of code. The developer may still need to perform some minor editing of the code that the AI provides, Loomis explains. "It might be 80 or 90 percent of what they need, but it still requires a couple of changes. It's a productivity enhancement — not a developer replacement type of activity."
The article quotes a skeptical Gartner Distinguished Vice President and Analyst, who notes that IBM "has no case studies, at this time, to validate its claims."
Code vs human language (Score:2, Funny)
It should be easy for a computer to translate cobol, after all it was written for a computer in the first place.
Re:Code vs human language (Score:5, Insightful)
One of the problems I can see is replicating all the edge cases that COBOL silently handles one way but the new language might either throw an exception or handle differently.
Mapping all the Hollerith columns to variables, making sure type casting in the new language matches COBOL's method, matching operands in COBOL to functions in the target language including errors and exceptions, etc.
Yes, it can be done but it will take thousands of sample data sets with known output results to begin to learn what translation methods into the target language approximate the way COBOL processes that data.
I remember programming in COBOL in my CS courses in college. A single extra space at the end of a data line in a 500-record set crashed everyone's programs. Not many text editors allowed you to easily spot an extra space at the end of a line. Parsing fixed-length input data is hardly a new task, but the translation will need to know how to handle these problems the same way COBOL does.
Re: (Score:3)
M-x whitespace-mode.
Re: (Score:3)
Was there an "Emacs mode for that" 40 years ago, though?
Re: (Score:2)
Oops, bad moderation
Re: (Score:3)
You do know that EMACS was first released as macros for the TECO editor in 1976,and GNU EMACS was first released in 1984, fourty years ago next month.
Re: (Score:2)
I should have phrased the question differently, apparently.
I assume emacs was not "2023 feature complete" when it was initially released. Did the aforementioned "whitespace mode" exist in 1976?
Re: (Score:2)
Presumably, some of this could be done by parsing all the known changelogs? Here are the earliest ones in one file: https://git.savannah.gnu.org/c... [gnu.org]
Prior to 1984 however I am not sure where the release notes for non-gnu Emacs (if any exist) might be found.
If you specifically care about 1974 though, I think sed existe
Re: (Score:3)
IBM predicting the future with shitty whitespace based languages.
Re: (Score:2)
In this case, whitespace means that you didn't punch anything into that column of your punch card.
FORTRAN in those days had magical columns, too.
Re:Code vs human language (Score:4, Insightful)
An excellent illustration of why making whitespace significant in you-know-what is an antiquated idea... if you're not at least potentially using a punch card, there's no good reason for it.
Re: (Score:2)
COBOL was the second language I learned back in 1969 after Fortran and the only coding language I used until 1974 when I switched to systems programming mostly in Assembler. I was still using COBOL occasionally to update code until about 1985.
I call total bullshit on this post.
White space at the end of a line did not crash anything. The only columns on a card that were not code was the sequence number in columns one through eight leaving 72 columns for code, although with a compile time option the last eigh
Re: (Score:2)
I agree. These young i-jits think all COBOL was written on punch cards. By 1981, everything was online, typed into a terminal.
And whitespace (we're not talking typos here) didn't affect the COBOL compiler at all. How do you kids think we properly indented code?
Re: (Score:2)
I remember programming in COBOL in my CS courses in college. A single extra space at the end of a data line in a 500-record set crashed everyone's programs. Not many text editors allowed you to easily spot an extra space at the end of a line.
You had text editors?
We had punch cards, and you had to cut them out yourself from a big sheet of stock and some scissors...
Re: (Score:2)
You had scissors?!
Re: (Score:3)
yes, but only after we made shovels from rock,, and used that to dig up enough obsidian that we could chip into scissors.
Re: (Score:3)
Translating a COBOL program into, say, JAVA, will produce a program that no JAVA programmer would ever have written to solve the problem. It will have the same logic of the COBOL program by will be written in JAVA syntax. To pretend that AI will "injest" a COBOL program, infer it's purpose, and then code a JAVA program that implements the solution in a JAVA program that incorporates ANY unique JAVA features/capabilities.
Re: (Score:3)
One great example of these edge cases, is the Unisys flavor of COBOL, which was based on a 48-bit word. Arrays were often declared as one type, such as an array of 100 words, then cast as characters and used to store text. These types of tricks that we now consider taboo, will cause all kinds of issues for any kind of translator, AI or otherwise.
Re: (Score:2)
literacy.
i speak cobol.
so how much are we talking about here.
and nothing like the letters i b m to designate user unfriendliness
Re: (Score:3)
Re:Code vs human language (Score:5, Insightful)
I know Cobol. Cobol is easy to learn.
People who earn big bucks maintaining legacy Cobol are not paid those bucks because they "know Cobol" but because they have deep knowledge of the legacy system.
Machine translation of a legacy Cobol system into something like Java will solve nothing because the language isn't the problem.
These legacy systems have decades of hacks, workarounds, and special cases. Translation will make that worse.
Re: (Score:2)
Machine translation of a legacy Cobol system into something like Java will solve nothing because the language isn't the problem.
Translation of a legacy Cobol system into something like Java will solve nothing because that language is also a problem.
Re: (Score:2)
Re:Code vs human language (Score:4, Insightful)
Re: (Score:3)
It should be easy for a computer to translate cobol, after all it was written for a computer in the first place.
You maybe have said something that an AI might do that would be useful.
Instead of taking poorly understood COBOL code and converting that to java code, have it produce what should have been the comments of well documented code. That would make the sections of code the AI didn't understand more obvious, I think.
Then you could build from that using whatever language in the future ising whatever AI.
I have to suspect that a great deal of that legacy COBOL code has a logic that's based on 80 column card format.
Re: (Score:2)
Re: (Score:2)
They'd need to learn a bit more then just COBOL - they would need to learn IMS DB/DC. DB2, VSAM, and CICS to make sense of the code they hope to translate.
Re: (Score:2)
The issue isn't the COBOL code (its a language designed for non-technical users, like BASIC was), it's the eco-system of COBOL, VSAM, CICS, IMS and/or DB2.
You can't expect AI to "injest" a COBOL/VSAM/CICS/DB2 application, derive a set of requirements, and then code a JAVA/ORACLE/WEB application that properly implements the requirements.
The real issue is the poor documentation that defines the operation of the code - if it existed, they could just re-code the applications, unfortunately, the requirements onl
Re: (Score:2)
get next within parent. . . .
My first database training was on IMS, in community college.
Re: (Score:2)
It should be easy for a computer to translate cobol, after all it was written for a computer in the first place.
Ha Ha Ha.
Grace Hopper and friends created COBOL to allow non-programmers to develop business programs without having to become computer experts.
COBOL was not "written for a computer in the first place"...
Re: (Score:2)
It's a simple problem to solve. Use the compiler to generate the compiled assembly code. Then hire assembly programmers to maintain it!
Re: (Score:2)
You mean, the System/360 assembly code? Good luck with finding assembly programmers for it :)
Although, to be honest, it's not bad at all, and looks surprisingly modern provided that System/360 is almost 60 years old at this point.
Re: (Score:2)
COBOL has already been ported to newer systems where I think it is used the most. Anyone keeping the old big irons going is already wasting money on keeping the hardware from collapsing.
Re: (Score:2)
In the late 1980s Lexeme was successfully translating source code. BLISS translated into LISP was horrific to look at, but it ran.
Don't need "AI" (Score:5, Interesting)
The company I worked for in the mid-to-late 90s was doing source-to-source transformation of COBOL which retained the semantics (mainly COBOL I and II to COBOL 370, but there were some COBOL to Java experiments as well). In fact we licensed these tools to IBM at the time.
You don't need "AI" to do this, you just need proper semantic tools.
Re: (Score:2)
You don't need "AI" to do this, you just need proper semantic tools.
But... but... how will you introduce critical bugs if you do the translation with a parser and loops and hard-coded conversion routines?
Re: Don't need "AI" (Score:3)
Easy: we'll have Watson convert COBOL to Forth.
Re: (Score:3)
Companies don't get sufficient PR cred with "semantic tools".
Re: (Score:2)
Re: (Score:2)
Are you talking about situations where people did extra smart assed tricks to make a mathematics operation faster by taking advantage of an undocumented feature? It seems like otherwise you keep the cruft by translating and keeping it rather than throwing it away even if it seems unnecessary.
Re: (Score:2)
Are you talking about situations where people did extra smart assed tricks to make a mathematics operation faster by taking advantage of an undocumented feature? It seems like otherwise you keep the cruft by translating and keeping it rather than throwing it away even if it seems unnecessary.
No I am talking about exceptions which maybe only sparsely documented or poorly understood. For example in a payment system there were a series of exemptions and benefits enacted at different times for different reasons. Sure it is listed somewhere in the company meetings in the last 30-40 years. But then the code was interdependent based on the systems at the time. Replace it with another system meant payments were missed which would mean other problems like penalties incurred if payments were missed. Who
Re: (Score:2)
Sure, but if you're using code translation tools there's no reason for them to throw those operations out just because they aren't understood, so long as they can be implemented. Just don't configure it to throw away processing that seems unnecessary.
Probably the easiest language to try this (Score:4, Insightful)
It's been decades since I've looked at COBOL - but since it was seemingly designed to be easily readable and parseable by humans, I'd think it would be a great candidate for machine translation. However I'm thinking of the old COBOL... it sounds like, more recently, they've attempted to hammer it into something it never was (object oriented). So who knows what that probable monstrosity looks like.
Re: (Score:3)
Why would you want that? (Score:4, Funny)
So, taking something some people can read and turning it into something no one can read.
Re: (Score:2)
Y2K (Score:3)
Does it answer why? (Score:5, Insightful)
The biggest problem with understanding code is not _what_ it does, but _why_ it does that.
Re: (Score:2)
The biggest problem with understanding code is not _what_ it does, but _why_ it does that.
Then look at the comments. OK, now you have TWO problems...
Re: (Score:2)
I worked for a quasi-government authority from the early 80s to early 90s.
They put out a tender to supply hardware and software to bring their systems from paper to computer.
IBM won the contract (supplied a System/36 with OS, and RPG and COBOL compilers), not because they were cheaper on paper, but because they offered to write the application software.
For free. We paid full price for hardware, operating system, and compilers, but they wrote the application software.
I inherited the system, and all the sourc
Re: (Score:2)
The biggest problem with understanding code is not _what_ it does, but _why_ it does that.
The biggest problem with preserving COBOL, is not treating it like every other language.
If you stopped training people that knew a language before, and you still NEED that language, then start training them again.
Why are we even debating the answer to this. Like every other language.
Re: (Score:2)
Your comment contains the answer to your ultimate question. You would have to train people. That costs money that nobody wants to let go of. It's more expensive to support more languages.
Meh (Score:3)
Re: (Score:2)
Yeah, but this uses the magic buzzword "AI", and we all fell for it and read TFA and posted about it, dammit.
In the meantime, IBM stock is up 1.7%* on the strength of this announcement, so it's served its purpose.
* Figure made up for the purposes of this post.
It's worse than that (Score:5, Insightful)
Many legacy computer systems are running binaries for which the source code no longer exists.
Cue question from the dispatch department, "Why are you trying to send a report to a destination that no longer exists?", to which the answer is, "It is produced by this program, but nobody knows why it is run and it can't be changed".
Re: (Score:2)
Many legacy computer systems are running binaries for which the source code no longer exists.
Cue question from the dispatch department, "Why are you trying to send a report to a destination that no longer exists?", to which the answer is, "It is produced by this program, but nobody knows why it is run and it can't be changed".
Greed over a period of decades decided to NOT invest in upgrading systems that were no longer supported, and pocketed the money as bonuses instead.
System went down and you can't get it back up? Oh, the WHOLE company is offline? Ain't that a bitch. Now where did I put that tiny tiny violin.
IT/Security professionals really NEED to learn to speak the dialect of DR better. Even if that means walking over to the outlet and pulling the power cord to prove the point to the CxO bragging about how 'prepared' the
Re: (Score:2)
Greed over a period of decades decided to NOT invest in upgrading systems that were no longer supported, and pocketed the money as bonuses instead.
System went down and you can't get it back up?
Failing and irreplaceable hardware is not actually the problem here. Because emulation exists, at least. A fun fact: Unisys still sells new mainframes from the decades-old "Burroughs B5xxx" and "Univac 1100/2200" series, fully able to run the old compiled binaries, created 50 or more years ago, only much faster. The new "mainframes" in question are actually AMD64-based PCs emulating the old hardware.
Running the old programs is not a problem. Modifying them is. If such a program had its source code available
Re: (Score:2)
That seems also a failure of management of the application. If the software can only send to that address, then that address is part of it.
yes. for 20 years (Score:1)
Nothing new here, when I worked at IBM in the early 2000's they alreay did conversion projects that transpiled cobol to java. This is just marketing, surfing the gen AI hype.
Re: (Score:1)
If Watson is that good, why can it not translate to another language with 100% fealty that IBM would warrant?
The big question is: Into what? (Score:3)
I mean we are not talking about some hobbyist projects where it doesn't matter if it won't compile in 20 years. We are talking about business software which is used for 50 years and expected to still work in 50 years. There is currently no high-level language which is that stable and provides useful abstractions for those use cases.
That's probably the main reason why those projects fail. I mean automatic translation from one language to another one is a solved problem, it's called "compiling" and people do it every time.
Re: (Score:1)
It's impossible to explain this to the 'coders' who seem to think that languages and tools spoil if they're left out overnight. Gotta get the flavor of the month on the resume, after all.
COBOL has a lot going for it. It's easy to read, easy to write, and ludicrously fast. That's no exaggeration. I don't think too many developers today can even conceive of exactly how impressive the performance of the average COBOL program is. That's big part of why so many COBOL to Java projects failed in the 90's.
Oh,
Re: (Score:2)
COBOL has a lot going for it. It's easy to read, easy to write, and ludicrously fast. That's no exaggeration. I don't think too many developers today can even conceive of exactly how impressive the performance of the average COBOL program is. That's big part of why so many COBOL to Java projects failed in the 90's.
COBOL and the mainframes they ran on were optimized for massive datasets and batch processing - PCs (x86 servers) were not, and crumbled under the load.
It would probably be cheaper to make (Score:2)
It would probably be cheaper to make COBOL cool
Re: (Score:2)
I take it you've never looked at COBOL code.
That's not the problem (Score:2)
The problem is that nobody knows anymore WHAT the code does, nor HOW and sure enough not WHY this way and not that one.
If AI gets good enough to understand all the reasons it was done that way, limits of the language, structure, variable handling etc it could work.
AI discussion hides the real corporate problem (Score:1)
Re:AI discussion hides the real corporate problem (Score:4, Informative)
Yes and no. Granted companies do not want to pay for re-writing software. However, those COBOL programs have been around for a long time and have the majority of their bugs worked out, so ongoing maintenance is minimal. New code has to be supported, and its bugs will appear over the next decade. And there is no guarantee that the code language you write in now will be supported...except maybe C.
Large companies also have accountants that are able (we think) to evaluate risk vs. reword. That's why we have so many security exploits. The accountants figure it is cheaper to accept the risk of an exploit that to invest in making their system bulletproof, and that itself won't ensure no risk in the future. The fact that customers get screwed via an exploit has been factored in. The accountants are paid to evaluate risk to the company, not to the customers. And that is why the dead hand of the free market is not going to solve our security issues. The external costs have to be inflicted on those companies outside of the free market.
Re: (Score:2)
COBOL conversion project don't fail because companies don't want to pay for talent, they fail because today's hotshot developers don't understand the first thing about writing efficient and maintainable code.
As for technical debt, it's really hard to claim that the more than 40-year-old code powering your business hasn't paid for itself time and again. Technical debt is when you're replacing core systems every 5-10 years because a vendor stopped supporting whatever fad platform was all the rage the last tim
Re: (Score:2)
Real world (Score:4, Insightful)
- We have the source code. We think that the compiled version we are is different than the source code we have though.
- We have the source code but itâ€(TM)s uncommented. Itâ€(TM)s also on paper. Weâ€(TM)re not sure we have all the pages.
- We have the main source code. Thereâ€(TM)s some support programs that were written in Algol and ibm 370 assembler that we lost the code and compilers for.
- We have the source code. Itâ€(TM)s in these boxes of 9 track tapes.
- We have the source code. The compiler is refusing to run because itâ€(TM)s missing a license code tied to the cpu version. The compiler company went away 30 years ago.
- We have the source code. The compiler refuses to compile the source code and weâ€(TM)re not sure why.
Re: (Score:3)
Re: (Score:2)
I used to work at a 4-person startup where I was tasked with a few different electronics projects. A coworker would always insist that I not use an MCU. I ended up building a test signal generator that would sequentially stimulate all the channels of a large data acquisition from an analog sinewave generator (opamp, caps, etc.), some analog switches, a digital counter/timer, and a demultiplexer. My coworkers were happy.
Later, I ran into a board space constraint and wanted to use a very tiny MCU for some
Re: (Score:2)
Maybe support possible new developers. (Score:1)
Don't use Java, never Java! (Score:3)
This post, and the problem IBM is trying to solve, is the major problem we have in Software Engineering. No one wants to modernize anything, because it was written 10, 20, or 30 years ago, and the teams are still understaffed, under budget, under resourced. They also generally lack enough qualified staff, and that leads to program rot. A good rule of thumb is to review your code every 6 months to a year, and make updates where they make sense, and to bring your code into modern standards, or, change the language / framework.
5 years ago when Framework X went EOL, I didn't complain and keep using it, I ported our entire code base ~125k lines of code, to a new framework. That took ~1 year to do, but when it was done we didn't have to worry about being on an EOL framework. The same is true for languages, If what you're using now doesn't make sense, even if it did 10 years ago, move languages! One of the other things I normally work on, is moving old code bases from X to Y, sometimes that's C to GO, or JavaScript to GO, or VB to C. It doesn't really matter what you move from and to, proving that “to” is well-supported, and if in 5 years “to” is no longer supported move again. You might have to do this on your own time, because companies rarely want to invest into meaningful retro support, but welcome to Software Engineering, more on the Engineering side of that title.
Re: (Score:2)
\No one wants to modernize anything, because it was written 10, 20, or 30 years ago, and the teams are still understaffed, under budget, under resourced. They also generally lack enough qualified staff, and that leads to program rot. A good rule of thumb is to review your code every 6 months to a year, and make updates where they make sense, and to bring your code into modern standards, or, change the language / framework.
Why does code need modernized at all? Banks don't like losing money. Their code is decades old and thoroughly vetted. Doing any updates for the sake up updates is asking for trouble.
Re: (Score:2)
If you talk with senior level IT, software engineers, security engineers at banks, they'll o
Re: (Score:2)
As the time since last change goes up, so does the resistance to making the next change. At some point nobody will want to change the thing at all, instead pile on some additional layer to effect a modification that should properly have been done in the underlying application. Now you've spread your business logic over a larger area and made future changes a little harder.
IOW, inertia exists. A thing that hasn't changed eventually morphs into something that cannot be changed. Something that is changed regul
Which is what I did in the 90s for a living (Score:2)
That last ten percent... (Score:2)
The developer may still need to perform some minor editing of the code that the AI provides, Loomis explains. "It might be 80 or 90 percent of what they need...
What's that famous anecdote about Steinmetz? $1 for the chalk mark, $9999 for knowing where to put it?
The cobol cowboys and cowgirls (hi Mom!) are going to have their hands for full for the foreseeable future if a 90% solution is the best that the generative AI crowd can come up with.
Resources (Score:2)
Re: (Score:2)
To be fair, Java is an exceptionally crappy language.
Re: (Score:2)
I remember reading a story some years ago about how modernizing an application from Cobol to Java multiplied the memory usage significantly. I suppose they will have to invest a lot in hardware.
They will certainly have to invest in a lot more hardware, but you get a lot more hardware for your dollar than you did back when COBOL was fashionable. We all like to complain about how inefficient software is today, and occasionally even with good reason, but for the most part the systems are so much more powerful that it doesn't really matter.
No (Score:2)
Obviously, with good machine and runtime specs, you just could cross-compile to a different language, no AI needed. In the absence of that, you need actual insight into the code and how it runs to translate it. No AI has that.
Doing some 50% or 90% translation is not going to cut it either. That will probably not even safe effort on the part of the actual experts that have to clean up the mess.
Secret method (Score:2)
Here is the secret method to translate all COBOL code: a COBOL compiler.
IBM Professional Services (Score:2)
After IBM and the customer have a thorough understanding of the application landscape, the data flow, and the existing dependencies, "we help them refactor their applications," says IBM's Vice President of Product Management, IT Automation, Keri Olson.
Anyone who has been an IBM customer can see what's happening here...
"But most school's [...]" (Score:2)
But most school's don't teach the mainframe programming language COBOL any more [...]
Do most schools teach about when to use apostrophes?
Many niche languages have this problem (Score:3)
Because COBOL was developed in the era before software developers could find mates and reproduce, all native speakers of the language are now in their sixties or older. Anthropologists are now seeking funding to set up a COBOL Preservation Park somewhere in a large urban area. It would be equipped with zealously preserved mainframes, a kitchen that can prepare the speakers' specialized diet of ramen and fatburgers, keypunches, blackboards, vending machines and coffeepots, all mounted in a diorama featuring period cultural artifacts like anti Vietnam war graffiti. It is hoped that the grey-bearded protohumans who used COBOL will be motivated to produce new, even epic works in this language.
Transformting a hard problem into a worse problem (Score:2)
Reading code written in an an unfamiliar language is annoying but it is still much easier than reading code that produced by an unknown machine transform. The latter cannot even be trusted to be correct. At best machine transforms can be useful to make a human doing the conversions more productive. Even then, the transforms are likely to contain mistakes and be under documented in the quest for maximum productivity.
Just like many old, run-down buildings (Score:2)
A lot of old software just needs to die or be demolished.
This problem will sort itself out. If the code is valuable enough to be preserved, companies or people will spend the money to preserve / translate it. If the code isn't valuable enough to spend that kind of money on, then it will disappear, and may it rest in peace.
People always think the magic is in the code (Score:2)
It's not. The magic is in the requirements.
If you know the requirements, you can rewrite the code. If you don't know the requirements, reverse engineering (or translating) the code won't tell you what the requirements should be. You'll get new code that has some of the old bugs, plus some new bugs that result from the translation, and nobody will know what is a bug and what is intended.
Why Java? Why not something like Ada? (Score:2)
Re: (Score:2)
No sane person would willingly translate code into Ada.
Don't get me wrong, it's an interesting language and might provide some short term amusement, but there are much better languages to write in that do much better at the things Ada does well.
Re: (Score:2)
http://www.iaeng.org/publicati... [iaeng.org]
https://community.cadence.com/... [cadence.com]
AI cross-compiler? (Score:2)
Is this really supposed to be something revolutionary?
I'm a retired coder. I guess you could call me a COBOL Cowboy even.
The first real program I wrote, back in 1980, was a compiler. It took instructions in one language, GW Basic, and converted it to another language, machine code. No AI involved. That's what compilers do. I was told years later in college that compilers were an advanced subject and I could not take those courses until my 3rd year into the CS degr
Re: (Score:2)
Re: (Score:2)
According to my personal experience, Basic code form the 1980s tends to be like like the winners of the Obfuscated C code contests. No AI could help you with that, I'm afraid.
FYI (Score:2)
There's a COBOL module in gcc, so it can compile COBOL.
When you can't fool Gartner (Score:2)
A sure sign you have truly failed, is Gartner doesn't breathlessly believe you.