[DISCUSS] IBM using LLMs to convert COBOL to Java

It’s not the 1st time a language/tool will be lost to the annals of the job market, eg VB6 or FoxPro. Though previously all such cases used to happen gradually, giving most people enough time to adapt to the changes.

I wonder what’s it going to be like this time now that the machine, w/ the help of humans of course, can accomplish an otherwise multi-month risky corporate project much faster? What happens to all those COBOL developer jobs?

Pray share your thoughts, esp if you’re a COBOL professional and have more context around the implication of this announcement 🙏

ImpossibleRubiksCube,

I think IBM is going to immediately regret this immediate decision.

PeterPoopshit,

But then at least by the time they get it working, they’ll have enough practice to make a new llm to convert their Java code to a useful programming language.

Java is definitely a programming language but good luck actually getting it to compile on anyone else’s machine besides the person who wrote the project.

ImpossibleRubiksCube,

It’s definitely one of the programming languages of all time.

loutr,
@loutr@sh.itjust.works avatar

Well that’s a new one, in most cases modern Java projects are built by simply running “./mvnw package”, on every platform.

MargotRobbie,

Why Java instead of C# or Go though?

loutr,
@loutr@sh.itjust.works avatar

Because Cobol is mainly used in an enterprise environment, where they most likely already run Java software which interfaces with the old Cobol software. Plus modern Java is a pretty good language, it’s not 2005 anymore.

PuppyOSAndCoffee,

Java is a POS and that’s before log4j.

quicken,

Because IBM doesn’t want to tie themselves to Google or Microsoft. They already have their own builds of OpenJDK.

PuppyOSAndCoffee,

No. Because IBM sells WebSphere, so java it is so they can up sell you for more contract labor.

nomadjoanne,

This might be a stupid question, but how is this different from cross compilers? Is it more natural and readable?

spauldo,

“Cross compiler” usually means a compiler that generates machine code for a machine other than what it runs on. For example, a compiler that runs on X86_64 but creates binaries for Atmel microcontrollers.

You might be thinking of transpilers, which produce source code in a different language. The f2c Fortran-to-C compiler is an example of that.

In my experience, transpiler output is practically unusable to a human reader. I’m guessing (I haven’t read the article) that IBM is using AI to convert COBOL to readable, maintainable Java. If it can do so without errors, that’s a big deal for mainframe users.

nomadjoanne,

Transpiler, that’s it. And thanks for your answer.

Pavlichenko_Fan_Club,

Oh FFS there is nothing magical about COBOL like its some kind of sword in the stone which only a chosen few can draw. COBOL is simple(-ish), COBOL is verbose. That’s why there is so much of it.

The reason you don’t see new developers flocking to these mythical high-paying COBOL jobs is its not about the language, but rather about maintaining these gianourmous, mission-critical applications that are basically black boxes due to the loss of institutional knowledge. Very high risk with almost no tangible, immediate reward–so don’t touch it. Not something you can just throw a new developer at and hope for the best, the only person who knew this stuff was some guy named “John”, and he retired 15 years ago! Etc, etc.

Also this is IBM were talking about, so purely buzzword-driven development. IBM isn’t exactly known for pushing the envelope recently. Plus transpilers have existed as a concept since… Forever basically? Doubt anything more will come from this other than upselling existing IBM contracts who are already replacing COBOL.

Duamerthrax,

Though previously all such cases used to happen gradually, giving most people enough time to adapt to the changes.

The Luddites would like to have a word with you.

HowMany,

So a ‘compiler’ then? From a fairly straightforward easy to use COBOL to whatever. makes sense. can the new code work in the mainframe environment? or is that what this piracy is about?

har har har.

:D

halfempty,
halfempty avatar

That's alot of effort to go from one horrible programming language to another horrible programming language.

PuppyOSAndCoffee,

Yes. Leave it to IBM to take a terrible idea and make it worse.

juja,

What would your language of choice have been? And why is java horrible for this scenario? it sounds like a reasonably good choice to me

pastermil,

Python, anyone?

orangeboats,

Not nearly as performant as either Java or COBOL.

PuppyOSAndCoffee,

What

Java is a POS and mainframes run faster emulated on a rasberry pi vs the actual hw.

The real answer is you want a typed language with financial transactions. But even python would be better than Java.

ImpossibleRubiksCube,

Can’t wait for Python to take fifteen minutes for me to make an ATM transaction…

infamous_trade,

javascript

cow,
@cow@lemmy.world avatar

JavaScript is worse than COBOL.

ImpossibleRubiksCube,

JEEEZUS CHRIST MAN.

TacoNissan,

JavaScript is actually really nice as a beginner programming language because of how quickly and visually you can see your results, and how easily you can debug with console output. Yeah it’s horribly unoptimized but it’s not for big things. It’s for little things. It’s baby’s first programming language.

PuppyOSAndCoffee, (edited )

It actually is pretty quick. Dont sleep on JavaScript capabilities. However, it is untyped. You wouldn’t want the date you wrote your check to become the amount of your check, for example.

TypeScript does a nice job there but all in all at that point might as well go all in on a typed language.

AttackPanda,

I’m assuming there is an implied /s here

AttackPanda,

I’m thinking Go or Rust would be the logical next step. They probably won’t want an interpreted language so Python is out.

Bene7rddso,

If they don’t want interpreted Java is out too

PuppyOSAndCoffee,

Rust - absolutely.

juja,

Just curious, what about go or rust makes them the logical next choice and not java? What do go or rust do better that java doesn’t?

PuppyOSAndCoffee, (edited )

Java is an Oracle honey pot, a royal sustainment PIA, massive security liability, clutters up systems with its nonsense and slow as shit.

“dear diary, despite running on a system with 1TB of RAM, a routine security patch reset the Java max memory quota and now every Java process stops after 256MB of object allocation. All four threads ran out of memory with 999GB RAM free. Thank you for this wonderful and blessed gift of computational ineptitude, amen.”

argv_minus_one,

If even highly skilled humans couldn’t do that, artificial pseudointelligence doesn’t stand a chance in hell.

There’s nothing of substance here. Just suits chasing buzzwords. Nothing will actually happen, just like nothing actually happened every other time some fancy new programming language or methodology came along and tried to replace COBOL, including Java.

duncesplayed,

This is what I don’t get. Rewriting COBOL code into Java code is dead easy. You could teach a junior dev COBOL (assuming this hasn’t been banned under the Geneva Convention yet) and have them spitting out Java code in weeks for a lot cheaper.

The problem isn’t converting COBOL code to Java code. The problem is converting COBOL code to Java code so that it cannot ever possibly have even the most minute difference or bug under any possible circumstances ever. Even the tiniest tiniest little “oh well that’s just a silly little thing” bug could cost billions of dollars in the financial world. That’s why you need to pay COBOL experts millions of dollars to manage your COBOL code.

I don’t understand what person looked at this problem and said “You know what never does anything wrong or makes any mistake ever? Generative AI”

PuppyOSAndCoffee,

Ooh good point

What if IBM had a product that did the COBOL->Java conversion (no what if tbh, believe it exists), then just changed the marketing material to make it seem flashy?

So like, you think it’s Ai but really it’s the same grammar translation functions that have been around for ever.

socsa,

What a terrible day to be literate

4stringscooter,

So the fintech companies who rely on that tested (though unliked) lump of iron from IBM running an OS, language, and architecture built to do fast, high-throughput transactional work should trust AI to turn it into Java code to run on hardware and infrastructure of their own choosing without having architected the whole migration from the ground up?

Don’t get me wrong, I want to see the world move away from cobol and ancient big blue hardware, but there are safer ways to do this and the investment cost would likely be worth it.

Can you tell I work in fintech?

Puzzle_Sluts_4Ever,

If you do this before everyone who can understand and maintain the cobol code retire, this is no different than a large scale planned migration. Except you don’t need to find code monkeys to transliterate and the code is generated in minutes (really seconds)

dontcarebear,

Cobol, the legacy Fintech curse. If LLMs make the work of translation possible, then that alone makes all that R&D worth it.

eyy,

Not a cobol professional but i know companies that have tried (and failed) to migrate from cobol to java because of the enormously high stakes involved (usually financial).

LLMs can speed up the process, but ultimately nobody is going to just say “yes, let’s accept all suggested changes the LLM makes”. The risk appetite of companies won’t change because of LLMs.

Kache,

Wonder what makes it so difficult. “Cobol to Java” doesn’t sound like an impossible task since transpilers exist. Maybe they can’t get similar performance characteristics in the auto-transpiled code?

DefinitelyNotAPhone,
@DefinitelyNotAPhone@hexbear.net avatar

Translating it isn’t the difficult part. It’s convincing a board room full of billionaires that they should flip the switch and risk having their entire system go down for a day because somebody missed a bug in the code and then having to explain to some combination of very angry other billionaires and very angry financial regulators why they broke the economy for the day.

Skiptrace,

Well, I’d rather the day be sooner than later. Also, this is why you have… Backup servers and development environments. You don’t just flick the Switch randomly one day after code is made. You run months and months of simulated transactions on the new code until you get an adequate amount of bugs fixed.

There will come a time when these old COBOL machines will just straight die, and they can’t be assed to keep making new hardware for them. And the programmers will all die out too. And then your shit out of luck. I’d rather the last few remaining COBOL programmers help translate to some other long lasting language before they all kick the bucket and not after.

PuppyOSAndCoffee,

Nah, dump it all.

COBOL programs don’t handle utf8 and other modern things like truly variable length strings.

Best thing to do is refactor and periodically test by turning off the mainframe system to see what breaks. Why something was done is lost to the sands of time at this point.

DefinitelyNotAPhone,
@DefinitelyNotAPhone@hexbear.net avatar

Well, I’d rather the day be sooner than later.

Agreed, but we’re not the ones making the decision. And the people who are have two options: move forward with a risky, expensive, and potentially career-ending move with no benefits other than the system being a little more maintainable, or continuing on with business-as-usual and earning massive sums of money they can use to buy a bigger yacht next year. It’s a pretty obvious decision, and the consequences will probably fall on whoever takes over after they move on or retire, so who cares about the long term consequences?

You run months and months of simulated transactions on the new code until you get an adequate amount of bugs fixed.

The stakes in financial services is so much higher than typical software. If some API has 0.01% downtime or errors, nobody gives a shit. If your bank drops 1 out of every 1000 transactions, people lose their life savings. Even the most stringent of testing and staging environments don’t guarantee the level of accuracy required without truly monstrous sums of money being thrown at it, which leads us back to my point above about risk vs yachts.

There will come a time when these old COBOL machines will just straight die, and they can’t be assed to keep making new hardware for them.

Contrary to popular belief, most mainframes are pretty new machines. IBM is basically afloat purely because giant banks and government institutions would rather just shell out a few hundred thousand every few years for a new, better Z-frame than going through the nightmare that is a migration.

If you’re starting to think “wow, this system is doomed to collapse under its own weight and the people in charge are actively incentivized to not do anything about it,” then you’re paying attention and should probably start extending that thought process to everything else around you on a daily basis.

Skiptrace,

When you say it like that… God bless America this whole system is doomed.

qaz, (edited )

COBOL programs are structured very differently from Java. For example; you can’t just declare a variable, you have to add it to the working storage section at the top of the program.

Kache, (edited )

That example doesn’t sound particularly difficult. I’m not saying it’d be trivial, but it should be approximately as difficult as writing a compiler. Seems like the real problem is not a technical one.

eyy, (edited )

It’s never been a technical reason, it’s the fact that most systems still running on COBOL are live, can’t be easily paused, and there’s an extremely high risk of enormous consequences for failure. Banks are a great example of this - hundreds of thousands of transactions per hour (or more), you can’t easily create a backup because even while you’re backing up more business logic and more records are being created, you can’t just tell people “hey we’re shutting off our system for 2 months, come back and get your money later”, and if you fuck up during the migration and rectify it within in hour, you would have caused hundreds/thousands of people to lose some money, and god forbid there was one unlucky SOB who tried to transfer their life savings during that one hour.

And don’t forget the testing that needs to be done - you can’t even have an undeclared variable that somehow causes an overflow error when a user with a specific attribute deposits a specific amount of money in a specific branch code when Venus and Mars are aligned on a Tuesday.

PuppyOSAndCoffee, (edited )

What.

Most cobol systems have more code that doesn’t do anything vs code that actually does something.

The grammar of COBOL + shit UI of mainframes means there is a shit ton of tribal anti pattern with each program. It is a pia to add fields and variables, so lazy programmers would just reuse something that wasn’t being used at that instant. Less work and more job security.

What values do variables ROBERT1, ROBERT2 and ROBERT3 hold? Whatever ROBERT wanted.

The reason why these things still exist is business laziness. They don’t know and don’t care what cobol is or isn’t doing.

I am struck by … conversion to … Java? Really??? lol.

eyy,

Most cobol systems have more code that doesn’t do anything vs code that actually does something.

What values do variables ROBERT1, ROBERT2 and ROBERT3 hold? Whatever ROBERT wanted.

And when that system is storing high-risk and/or sensitive data, do you really want to be the person who deletes code that you think “actually does nothing”, only to find out it somehow stopped another portion of code from breaking?

The reason why these things still exist is business laziness. They don’t know and don’t care what cobol is or isn’t doing.

That’s the thing - tor a risk-averse industry (most companies running COBOL systems belong here), being the guy who architected the move away from COBOL is a high-risk, high-stress job with little immediate rewards. At best, the move goes seamlessly, and management knows you as “the guy who updated our OS or something and saved us some money but took a few years to do it, while Bob updated our HR system and saved a bunch of money in 1 year”. At worst, you accidentally break something, and now you have a fiasco on your hands.

PuppyOSAndCoffee,

Org change vs vertical integration, which is worse and why in 500 words or less ;)

Pay now or pay later…the organization is going to get kicked in the nuts.

For industries that have the option, companies who got kicked in the nuts ten yrs ago are doing better today than those who are still waiting.

IBM should shoulder a lot of the blame, there really is no reason why COBOL couldn’t be phased out in place except it would hurt IBM market share so it is not exactly a “thing”. In place transition to RUST should just be another section of the zOS manual.

Treczoks,

“all those COBOL developer jobs” nowadays probably fit in one bus. That’s why every company that can afford it moves away from COBOL.

HubertManne,
HubertManne avatar

Im sorta excited for stuff like this to get going in terms of video games. There are some great games and it would be great if it was easier to pull it into a more modern engine or such.

Zeth0s,

Of all modern languages, why java? Which will likely soon become legacy for backend applications

datendefekt,
@datendefekt@lemmy.ml avatar

Sadly, I’ve haven’t been programming for a while, but I did program Java. Why do you consider it legacy and do you see a specific language replacing it?

M0ty,

Kotlin

datendefekt,
@datendefekt@lemmy.ml avatar

I was pretty impressed by what I saw from Kotlin. Pragmatic and terse, not as academic as Java. Reminds me of the shift away from EJB to Spring. Have been reading up on Rust and thought that with the LVM and WebAssembly (also for the backend), it is perfectly positioned as an alternative. What do you think?

DarkenLM,

Would you prefer Javascript?

M0ty,

Suuurely there are more languages to choose from

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • technology@lemmy.ml
  • DreamBathrooms
  • ngwrru68w68
  • modclub
  • magazineikmin
  • thenastyranch
  • rosin
  • khanakhh
  • InstantRegret
  • Youngstown
  • slotface
  • Durango
  • kavyap
  • mdbf
  • GTA5RPClips
  • JUstTest
  • tacticalgear
  • normalnudes
  • tester
  • osvaldo12
  • everett
  • cubers
  • ethstaker
  • anitta
  • provamag3
  • Leos
  • cisconetworking
  • megavids
  • lostlight
  • All magazines
    •