Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The IRS’s Effort to Convert Its Assembly Codebase to Java

federalnewsradio.com

Post reply on HN
Print view View original

201–210 of 224 posts

Re: The IRS’s Effort to Convert Its Assembly Codebase to Java

#201

Post by shagie »

ScottBurson wrote: post #155
lazaroclapp wrote: post #125

Earlier quoted context omitted.

> If the government is worried about trojans, malware, etc., then they can easily hire an auditor to audit the code and vouch for its authenticity. Not that I disagree with the general idea of democratizing this sort of big government contract, but, well, this is a much bigger hurdle than you are making it sound like. Audits can be good at finding unintentional flaws, but a skilled adversary can often create code tha…

I don't suppose those Java examples were published? I'd love to see them.

How about a nice, simple, 2 + 2 = 5? https://codegolf.stackexchange.com/a/28818

Re: The IRS’s Effort to Convert Its Assembly Codebase to Java

#202

Post by pjmlp »

TimJYoung wrote: post #48
jacquesm wrote: post #12

Earlier quoted context omitted.

The big trick is the proposal itself. Writing that is only possible if you are already tied in at all kinds of levels. I've seen some of these tenders up close, the companies that land the deals submit phone book sized proposals to tenders that are officially open but actually closed unless you are in a very select circle already. It's not uncommon for the proposal writer to then pass on the actual work to a whole sl…

Thanks, I suspected that this was the case after I read the Cringely book on IBM ( https://www.amazon.com/Decline-Fall-IBM-American-Icon-ebook/... ). It gives one the distinct impression that connections matter a lot , and that getting the contract matters more than actually completing it successfully.

This applies to all big corporations, not only government related projects.

Re: The IRS’s Effort to Convert Its Assembly Codebase to Java

#203

Post by AlexCoventry »

fwip wrote: post #193
AlexCoventry wrote: post #80

It sounds like the effort might have been a step in the right direction, but hardly a solution in its own right. The result would be a literal case of the aphorism "You can write assembly in any language." The translation would have some minor benefits: interop with java libraries would be nice, it could help to plug the system into better infrastructure like a modern testing framework, and it might run a little more…

If you can separate areas of functionality, you can upgrade it piece-by-piece. So while it starts off as 98% inscrutable assembly-in-Java, you transform it over time until it's only 2%. Ideally, backed with strong tests and fuzzing.

Absolutely, but it's a long way from a solution.

Re: The IRS’s Effort to Convert Its Assembly Codebase to Java

#204

Post by tzs »

slededit wrote: post #83
monocasa wrote: post #46

> in theory, there’s no way to translate assembler code. They way it runs is not how it reads Wat?

If you do crazy "tricks" to get the space down like self modifying code or jumping into data then it won't run how it reads. It's a lot easier to do this in assembly because data and code aren't distinct.

On the other hands, there are some "tricks" that someone trying to duplicate that functionality in a higher level language can do, too.

For example, our computers nowadays are much faster and have much more memory. So suppose you have some long, tricky section of assembly code that you know computers some sort of function of a single 32-bit input.

You could simply run that section, in a simulator, with all possible 32-bit inputs and make a table of the results. Then instead of trying to understand what is going on by following the convoluted assembly, your task is to implement the function given by that table. With the function in table form you can do things like look for sections that are linear, or constant, of follow other common patterns.

Hopefully you can get some idea from context in the assembly code what, at a high level, the function is doing, and that should further help you see patterns in the table.

Re: The IRS’s Effort to Convert Its Assembly Codebase to Java

#205

Post by e12e »

dragonwriter wrote: post #128
ww520 wrote: post #84

Earlier quoted context omitted.

It's the most difficult part of the project. However, nailing down the functionality upfront separates a successful project from a failed one. The implementation is the easy part. The functionality documentation will provide great value beyond this project. I assume this assembly program does the tax calculation, so the IRS tax code can be consulted to verify the functionality. Functional tests can be written against…

> It's the most difficult part of the project. However, nailing down the functionality upfront separates a successful project from a failed one. Yes, in that projects which try to reimplement large existing systems from the ground up by nailing down the requirements and working from there, almost invariably fail (even if they formally “succeed” in the sense of being accepted and then facing years of remediation.) You…

> Ship of Theseus replacement

This why java seems an odd choice; I can't imagine trying to run a codebase that's a split between assembly and java (keeping behaviour the same as more and more code is shifted).

The best idea I can see for that, is start with an interpreter for the assembler in java, moving procedure calls "up" into java.

But I imagine getting the interpreter good enough to run the same as the original target machine would be a huge task in itself.

[ed: leveraging clojure on the first iteration(s) might actually make the project feasible, though...]

Re: The IRS’s Effort to Convert Its Assembly Codebase to Java

#207

Post by carlmr »

cpncrunch wrote: post #171
gbacon wrote: post #164

Earlier quoted context omitted.

Probably. Maybe he should pick up a phone and bounce his simile off the programmers he contacted while preparing the piece.

The programmers probably don't know what a simile is :)

He just needs to tell them in his soliloquy.

Re: The IRS’s Effort to Convert Its Assembly Codebase to Java

#208

Post by cfstras »

TheSoftwareGuy wrote: post #21

Java seems like a good choice for the IRS. There are legions and legions of programmers well versed in Java, since its among the most commonly used programming languages to introduce programming at universities. This means the IRS should be able to focus its hiring on "People who know tax law and can use Java" instead of "Java experts that know enough tax law to be dangerous". Its not the flashiest language, but I th…

I don’t know how much validation the code does, but every single number in your tax forms is related to another by some statement in the law, and these change constantly. Validating them means codifying every single rule.

Germany figured this out a while ago and built a rule engine with GUI and small DSL where the lawyers can input tax rules to the database - meaning better code and you can emit for any platform. It’s called ElsterRules (Elster is the online tax filing program) and runs even in your browser... I wonder if there’s something similar in other countries.

Re: The IRS’s Effort to Convert Its Assembly Codebase to Java

#209

Post by sterlind »

e12e wrote: post #205
dragonwriter wrote: post #128

Earlier quoted context omitted.

> It's the most difficult part of the project. However, nailing down the functionality upfront separates a successful project from a failed one. Yes, in that projects which try to reimplement large existing systems from the ground up by nailing down the requirements and working from there, almost invariably fail (even if they formally “succeed” in the sense of being accepted and then facing years of remediation.) You…

> Ship of Theseus replacement This why java seems an odd choice; I can't imagine trying to run a codebase that's a split between assembly and java (keeping behaviour the same as more and more code is shifted). The best idea I can see for that, is start with an interpreter for the assembler in java, moving procedure calls "up" into java. But I imagine getting the interpreter good enough to run the same as the original…

ha, this is clever!

I imagine you might get the interpreter running up to spec by flipping actual mainframe to debug, then writing a supervisor at the interpreter's side that checks for parity at each instruction, then single-steps the physical machine.

Re: The IRS’s Effort to Convert Its Assembly Codebase to Java

#210

Post by phaemon »

cdelsolar wrote: post #161
dethswatch wrote: post #3

>assembler-to-Java project Where's my gif of that guy who looks skeptically at that thing he's looking at? You know that one.

Humor isn't allowed on Hacker News, you should know better.

Of course it is. The most points I've ever got for a single post, were for a one-line joke.

But then, my joke was funny.

Post reply on HN