> Fun (scary) fact – significant portions of the IRS tax system is still written in assembly.

Why is that scary? It has decades of real life testing applied to it if there were any obvious bugs they would have been found by now.

Assembly is just another language, it is slower to develop in but there are many examples of high level language issues that are at least as scary as what you could do in assembly. In the end it is all about the processes around your development as much or more than it is about what language you pick. The best way to reduce your chance of bugs is to reduce the size of your project.

https://www.mayerdan.com/ruby/2012/11/11/bugs-per-line-of-co...

But it's not something that was written once and has been used as-is for 40 years – it has constantly changed to match the tax code. The IRS has claimed that it is difficult for them to find engineers who can maintain it. After all, they didn't start a major project to port it to Java for no reason.

I also disagree with Mayer's assertions about LOC. In my professional experience, the best ways to avoid bugs are optimizing for clarity as well as continuously grooming your codebase (including modernizing when possible). Obviously the latter is not an option for safety-critical software, and probably not suitable for the tax system either. But in general, those practices have worked better for me than have others.

> <snip> if there were any obvious bugs they would have been found by now.

Really, that's what they said about CPUs - at least if you're not in the fab industry.

> Fun (scary) fact – significant portions of the IRS tax system is still written in assembly. It's basically the original codebase plus 40 years of additions and patches as the tax code changed.

> They were working on projects to "elevate" it to Java, because it's pretty difficult to maintain it as-is.

Yeah, apparently an eight person IRS development team nearly developed a replacement, but the main developers were hired on a special program to pay them at above-GSA rates, and that program expired before they could put it into production:

https://federalnewsradio.com/tom-temin-commentary/2018/01/ir...

Couldn't they open-source it? I assume finishing it would be relatively quick and a lot of comp-sci graduates would love to have the chance to play with IRS systems.

I'm guessing that would scare the crap out of the masses. Security by obscurity may not work but if there ever were a glitch or breach it sure does look bad to say "and they knew about the bug because we made our codebase public"

I don't think you could spin it that way. "The popular media can only handle ideas expressible in proto-language, not ideas requiring nested phrase-structure syntax for their exposition." Though maybe a better reason is that there doesn't seem to have been any such spin on big open source issues (such as Heartbleed) of the recent past. Why would they spin it as an open source problem rather than say a government/contractor competence problem (or something else) in the IRS case?

I mean, maintainability aside they are a giant calculator right? You don't need to be running the latest, hippest web platform to do a good job at doing a lot of math. And, will any of the current en-vogue tech still be working in 50 years?

If you had to pick, Java does make a lot of sense. Java & C are safe bets for "languages that will stick around for decades".

Having worked on financial code that is brittle and subject to far less minutiae than the multitude of IRS code, I can be very sympathetic on the complexity involved. It is hard to handle all of the complexity in a generic maintainable manner. I once ran into a 56-page printed function to calculate the margin required for a portfolio at a prime broker. Was it poorly written? Yes. Was it also representative of the complexity of the problem? Yes. Not an excuse for poor design, though.

I imagine processing the data, deciding whom to audit, and tracking the process is more complicated. Heck; they're probably using ML for audit red flags

How are they retaining staff with the skill-set to maintain that code?

They don't retain staff. But the ones who retire or leave can generally get a very large contract when things like this pop up.

Until, of course, they are all gone. At which point the system will need to be rewritten by IBM, Oracle or some other useless, gigantic consulting firm.

Its tough to recruit for, so you really end up with folks who have job security for the forseeable future and others who become retired-in-place because of the rarity of cleared folks eligible to take on the post.

Most big banks run on COBOL, new Fintechs run on micro-services powered by Go, JS or whatever's trendy at the moment. I trust software with a proven track record of several decades with no considerable downtime more than architecture that's currently considered to be "best practice".

NB: Don't object any of the new languages, I've never written code in COBOL or for a mainframe. But I've also never developed software with that kind of requirements.

Should it be written in Go, or Rust?

Because that always works so well ...

See the Chrysler Comprehensive Compensation fiasco: https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens...

These kinds of systems are all about the exceptions and how you enable humans to deal with those, not the rules and how the computer deals with those.

The problem is that the system first needs a comprehensive test suite written. THEN you could actually think about rewriting pieces.

I have sympathy for Rust but will it be easier to find Rust developers in 2040 than COBOL developers?

Depends on the decade you ask it.

Haskell. Obviously.