this post was submitted on 28 Mar 2025
730 points (99.1% liked)
Technology
68306 readers
4311 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related news or articles.
- Be excellent to each other!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
- Check for duplicates before posting, duplicates may be removed
- Accounts 7 days and younger will have their posts automatically removed.
Approved Bots
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Ah yes, a classic tale...
"We're going to take this perfectly efficient and functional COBOL code base and rewrite it in Java! And we'll do it in a few months!"
So many more competent people and organizations than them have already tried this and spectacularly crashed and burned. There are literal case studies on these types of failed endeavors.
I bet they'll do it in Waterfall too.
It's interesting. If they use Grok, this could well be the deathknell for vibe programming (at least for now). It's just fucking tragic that their hubris will cause grief and pain to so many Americans - and cost the lives of more than a few.
Edit: Fixed some typos.
They're not going to use Java, it's going to be typescript.
Or Rust
You think those script kiddies know Rust?
No, but they want to seem cool
And they’ll use Grok to write the code anyway 😂
Rust is not a language I'd use for financial apps, but it's not a bad language. So I doubt that they'd use it. Musk is of a generation where he'd probably tell them to use PHP. Or if he listens to the twenty-something bros around him, maybe it'd be Dart, which is another decent language that's not well suited to the problem domain.
Jokes aside, nothing wrong with rewriting in Java. It is well-suited for this kind of thing.
Rewriting it in anything without fully understanding the original code (the fact they think 150yo are collecting benefits tells me they don't) is the biggest mistake here. I own codebases much smaller than the SSA code and there are still things I don't fully understand about it AND I've caused outages because of it.
No. Java is not suited for this. This code runs on mainframes not some x86 shitbox cluster of dell blades. They literally could not purchase the hardware needed to switch to java in the timeline given. I get what you're trying to say but in this case Java is a hard no.
Uh, Java is specifically supported by IBM in the Power and Z ISA, and they have both their own distribution, and guides for writing Java programs for mainframes in particular.
This shouldn't be a surprise, because after Cobol, Java is the most enterprise language that has ever enterprised.
Non programmer but skilled with computers type guy here: what makes Java well suited for this?
This is probably an incorrect prejudice of mine, but I always thought those old languages are simpler and thus faster. Didn’t people used to rip on Java for being inefficient and too abstracted?
Last language I had any experience with was C++ in high school programming class in the early 2000s, so I’m very ignorant of anything modern.
They're neither necessarily simpler nor faster.
COBOL is simple, but outside its sweet spot, it can't do much. That sweet spot is high volumes of relatively trivial calculations, coded by non-superstar coders. It's moderately efficient because it doesn't do all that much.
Of the oldest languages still in use, FORTRAN has gone through a few generations of incremental improvements, and for complex mathematical calculations, it can be faster than shit off a hot shovel. But again, it's limited in scope, its data typing is lousy, its general-purpose programming capabilities are poor, and any integration you do with other systems is going to be a vision of hell. I still deal with a FORTRAN codebase on my job, there are some situations where it's still one of the least-bad options.
Then, the last of the surviving languages of that vintage is Lisp. It can be insanely fast, but despite its simple syntax and semantics, nobody would call Lisp programming simple. Accounting-system coders would recoil in horror.
Java can be pretty damn efficient for long running processes because it optimizes at runtime. It also can use new hardware features (like cpu instructions) without having to compile for specific platforms so in practice it gets a boost there. Honestly, the worst thing about Java is the weird corporate ecosystem that produces factoryfactory and other overengineered esoteric weirdness. It can also do FFI with anything that can bind via c ABI so if some part of the program needed some hand optimized code like something from BLAS it could be done that way.
All that to say it doesn't matter what language they use anyway, because rewriting from scratch with a short timeline is an insane thing to do that never works.
Yeah, Java can run maybe half as fast as equivalently complex C, while being far more maintainable. But to see that kind of performance, you'll want to use POJOs (plain old Java objects), not that enterprise bullshit. And there are many other optimization techniques that your average Java coder wouldn't see in their average coding job. I've been there, didn't like it. If I'm going to be dropping down to C for the hot spots, I'd rather use Python.
Schedule-driven development by people with no domain knowledge, with poorly understood requirements and life-and-limb-critical outcomes, led by an unpredictable moron. What could go wrong?
I wouldn't assume that Java is only half as fast as C for every workload. It's probably a lot closer than you think in a lot of real world scenarios.
Why is there a need to rewrite it at all? Is it because COBOL is basically ancient hieroglyphics to modern programmers thus making it hard to maintain or update?
COBOL code, like any code, was written to embody certain business processes, and also to work around the quirks and blind spots of COBOL. And the people who understood those business processes are likely to be dead by now, and any documentation they wrote might be current and correct, or it might not. And very few people under the age of 60 have ever used COBOL in anger. So any legacy replacement project is going to have to encompass a big reverse-engineering effort, including analysis of a code base nobody is familiar with.
I'm old. A friend of mine is a fair bit older, getting into his late 70s. He knows COBOL but his main area of expertise is OS services, database tuning and assembler on old IBM and Fujitsu iron. Those are critical to keeping those old systems running well. He works half-time, is booked over a year out, and has a jaw-dropping daily rate. He also has a rider: one provision is that they have to tell him where he can smoke on-site, and if the answer is "nowhere," the deal is off. Also, he won't schedule any work that conficts with Burning Man, and he looks like a homeless guy. I brought him in on a consulting gig once. He did his bit, including an amazingly effective presentation to the C-levels (despite his profoundly non-executive appearance), and went his merry way. Saved us a fortune. You need people like that in order to have even a remote chance of success, and they're becoming exceedingly rare. Musk and his kiddies don't even know what they don't know.
They want to make buttloads of money from a rewrite, and it would cost buttloads to do this. They probably also want things to run like shit and cause misery for retired Americans.
Refactoring a code base is kinda like general maintenance for the application. Over time deprecated features, temp fixes, etc. start to be a lot of the code base. By cleaning things up you can make it more maintainable, efficient, etc.
That being said, for systems this large you usually fix up parts of it and iterate over time. Trying to do the whole code base is hard cause it's like replacing the engine while the car is in motion.
I've worked on these "cost saving" government rewrites before. The problem is getting decades of domain logic and behavior down to where people can be productive. It takes a lot of care and nuance to do this well.
Since these nazi pea brains can't even secure a db properly I have my doubts they'll do this successfully.
Not just domain logic. The implementation logic is often weird too. Cobol systems have crash/restart behaviour and other obscure semantics that often end up being used in anger; it's like using exceptions for control flow, but exceedingly obscure and unfortunately (from what I've seen of production cobol) a "common trick" in lots of real-world deployments.
screams in quality assurance
Functional, yes. But rarely are these sorts of things efficient. They’re covered in decades of cruft and workarounds.
Which just makes them that much harder to port to a different language. Especially by some 19 year old who goes by “Big Balls”
My company actually wrote their flagship software in COBOL starting in the 80s, and we're only now six years into rewriting everything in a more modern language with probably four years to go.
I can't imagine trying to start such a project like rewriting all of Social Security and thinking it will take months. You have to be a special kind of fatuous to unironically think that.
I was briefly employed at a firm that maintained the sales commission software for a large telecom firm.
It was 1.5 million lines of VB6, though VB8 was already three years old. Nobody knew all of it, so they couldn’t possibly rewrite it to handle all the edge cases and special incentives we kept having to add.
Except maybe the lone QA person, who would frequently begin sobbing at her desk. And we could all hear it because it was an open plan office and we weren’t allowed to wear headphones.
That job was so bad I quit and began freelancing.
It's worth noting that one of those organizations is IBM. Mostly relevant because they're the ones that originally built a lot of that cobol, the mainframes it runs on, and even the compilers that compiled it.
They're basically the people you would expect to be able to do it, and they pretty quickly determined that the cost of a rewrite and handling all the downstream bugs and quirks would exceed the ongoing maintenance cost of just training new cobol developers.
My dad was a cobol developer (rather, a pascal developer using a compiler that transpiled to cobol which was then linked with the cobol libraries and recompiled for the mainframe), and before he retired they decided to try to replace everything with c#. Evidently a year later their system still took a week to run the nightly reports and they had rehired his former coworkers at exorbitant contractor rates.