Social Security systems contain tens of millions of lines of code written in COBOL, an archaic programming language. Safely rewriting that code would take years—DOGE wants it done in months.
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.
Probably a mix of Z systems, that stuff goes back 20-odd years, and even then older code can still run on new Z systems which is something IBM brags about.
Mainframes aren’t old they’re just niche technology, and that includes enterprise Java software.
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.
The way Java is practically written, most of the overhead (read: inefficient slowdown) happens on load time, rather than in the middle of execution. The amount of speedup in hardware since the early 2000s has also definitely made programmers less worried about smaller inefficiencies.
Languages like Python or JavaScript have a lot more overhead while they’re running, and are less well-suited to running a server that needs to respond quickly, but certainly can do the job well enough, if a bit worse compared to something like Java/C++/Rust. I suspect this is basically what they meant by Java being well-suited.
Java can be fast at runtime, but optimization is most effective on frequently-run, repetitive sections of code.
The slow Java interpreter spin-up time was a big annoyance for use of Java in serverless cloud functions. Now the big cloud providers have ways to minimize that spin-up delay.
I am a programmer but I’m not sure why people think Java is suited for anything, especially a system so sensitive to bugs. It’s so hard to write high quality readable code in Java. Everything is way more clunky, and verbose than it needs to be.
Some major improvements were made with versions 17+ but still, it feels like walking through mud.
It’s a language from the 1990s for the 1990s.
Btw the performance is actually pretty good in Java, the old reputation for slowness is entirely undeserved today.
It’s a verbose language but I don’t know if there’s any real language that encourages highly readable code beyond low-level syntax. You want to create a God-class in Python with nonsensical variables and 5 levels of nesting? The language won’t stop you.
Anecdotally, Python is about three times as concise as Java. You have to write lots of boilerplate to do anything much more complex than Hello World in Java. And one of the oldest and most reproducible results in software engineering is that the defect rate is proportional to the number of lines of executable code. The more concise the language, the cheaper it is to maintain. This has been measured in hundreds of environments, with dozens of languages, over decades.
Python is slow, though, so there are some situations where it’s not a good choice. But those cases are probably less numerous than you might assume. There have been a few occasions where I was told Python would be too slow, I’ve then built a proof-of-concept, and it was more than fast enough. People suck at knowing where bottlenecks are in complex systems.
And now that the Python project has finally bitten the bullet and taken measures to allow removal of the GIL, things might improve considerably, though Python’s dynamic nature and some features of its type inference mean that some things it does will never be ultra-speedy.
Other than hardware issues, which someone else mentioned, it has a lot of enterprise-grade functionality that make it more secure and auditable than a lot of other languages. And despite, or maybe because of, its large memory footprint it’s actually faster than most languages.
I totally get any hate about writing Java though. It is a verbose language. Using Kotlin instead helps with that.
I always thought those old languages are simpler and thus faster
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.
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.
How old do you think the mainframes running Social Security are?
Probably a mix of Z systems, that stuff goes back 20-odd years, and even then older code can still run on new Z systems which is something IBM brags about.
Mainframes aren’t old they’re just niche technology, and that includes enterprise Java software.
Think further back. Like late 80s to 90s IBM
Yeah, that’s what they said, 20 years or so ago
Ok this is gonna hurt. 2005 was 20 years ago
Old enough to collect benefits themselves
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.
The way Java is practically written, most of the overhead (read: inefficient slowdown) happens on load time, rather than in the middle of execution. The amount of speedup in hardware since the early 2000s has also definitely made programmers less worried about smaller inefficiencies.
Languages like Python or JavaScript have a lot more overhead while they’re running, and are less well-suited to running a server that needs to respond quickly, but certainly can do the job well enough, if a bit worse compared to something like Java/C++/Rust. I suspect this is basically what they meant by Java being well-suited.
Java can be fast at runtime, but optimization is most effective on frequently-run, repetitive sections of code.
The slow Java interpreter spin-up time was a big annoyance for use of Java in serverless cloud functions. Now the big cloud providers have ways to minimize that spin-up delay.
I am a programmer but I’m not sure why people think Java is suited for anything, especially a system so sensitive to bugs. It’s so hard to write high quality readable code in Java. Everything is way more clunky, and verbose than it needs to be.
Some major improvements were made with versions 17+ but still, it feels like walking through mud.
It’s a language from the 1990s for the 1990s.
Btw the performance is actually pretty good in Java, the old reputation for slowness is entirely undeserved today.
It’s a verbose language but I don’t know if there’s any real language that encourages highly readable code beyond low-level syntax. You want to create a God-class in Python with nonsensical variables and 5 levels of nesting? The language won’t stop you.
Anecdotally, Python is about three times as concise as Java. You have to write lots of boilerplate to do anything much more complex than Hello World in Java. And one of the oldest and most reproducible results in software engineering is that the defect rate is proportional to the number of lines of executable code. The more concise the language, the cheaper it is to maintain. This has been measured in hundreds of environments, with dozens of languages, over decades.
Python is slow, though, so there are some situations where it’s not a good choice. But those cases are probably less numerous than you might assume. There have been a few occasions where I was told Python would be too slow, I’ve then built a proof-of-concept, and it was more than fast enough. People suck at knowing where bottlenecks are in complex systems.
And now that the Python project has finally bitten the bullet and taken measures to allow removal of the GIL, things might improve considerably, though Python’s dynamic nature and some features of its type inference mean that some things it does will never be ultra-speedy.
Other than hardware issues, which someone else mentioned, it has a lot of enterprise-grade functionality that make it more secure and auditable than a lot of other languages. And despite, or maybe because of, its large memory footprint it’s actually faster than most languages.
I totally get any hate about writing Java though. It is a verbose language. Using Kotlin instead helps with that.
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.