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

211–220 of 224 posts

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

#211

Post by warrenm »

nicolaslem wrote: post #131
codemusings wrote: post #81

One has to wonder whether it really makes sense to port instead of taking a look at the workflow and simply implement it from scratch.

I maintain a code base written by others and I fight this feeling all the time. If (re)writing software has taught me anything is that sentences that start with "simply" or "just" actually mean that you don't fully understand the problem.

"simply implement" may be an understatement, but often enough, rewriting/reimplementing IS simpler (and cleaner, and more maintainable, etc etc etc) than keeping a legacy system going

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

#212

Post by warrenm »

cosmie wrote: post #104
zitterbewegung wrote: post #2

The best argument to new development is working code. I assume that they can't hire people to upgrade or maintain Maniframe software anymore.

Working code is king, but in the IRS's case it's a very expensive king. A huge amount of fraud happens by exploiting a timing attack against the batch processing architecture of the existing process. The system only has visibility into data from previous batches, it's blind to what's been done during the the currently processing batch. One exploitable artifact of this is that if you try to claim someone as a dependen…

Their batch processing is definitely an interesting case, as it how it processes failures (had them as a customer of mine a couple years back where I was working on improving their responses to failed jobs (and accelerating the time between reruns)).

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

#213

Post by agumonkey »

gbacon wrote: post #165
agumonkey wrote: post #57

Earlier quoted context omitted.

The more I study functional programming the more I see a mapping between structures (reduce/fold,...) and assembly. Assembly requires you to be very very careful, but if you're used to that you can encode these patterns in short ways. But it's a lost art nowadays.

That's opposed to the view often put forward by FP advocates. Tell us more.

Old cpus had a simpler arch (68000 ancestor or something like that), often with two registers A,B serving as accumulator,next pair for reduce/fold like processes. To me it's clearly a reflection of mathematical structures, which are also the root of FP.

With time register sets grew, ISA grew, this got muddied by usage.

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

#214

Post by gbacon »

robertha wrote: post #185
gbacon wrote: post #149

Earlier quoted context omitted.

Was your bid on the recent SBIR/STTR solicitation by chance?

Custom database product for EPA, seemed like a good fit. While I have no connections to EPA, I do some collaborative work with bio-engineering department at a university in Chicago, I'm a data scientist/developer/have a small team, I thought I'd try dipping my toes in something new.

Any technical people you were able to have discussions with in preparing your bid would be good places to start with follow-on conversations.

An acquaintance with a setup similar to yours does well with a virtuous cycle of rolling SBIR and STTR results into his commercial products, which fuel more SBIR wins. He also does lots of legwork in the form of hand delivering white papers he’s written in office calls with customers and potential customers during site visits.

People do business with people — particularly those we like, know, and trust — not companies and agencies. Find someone whose headache you can make go away. Keep the conversation moving.

This is a patient person’s game. Sometimes you’re planting seeds that will bloom later.

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

#215

Post by TimJYoung »

lazaroclapp wrote: post #125
TimJYoung wrote: post #7

Wow, what a cool project to work on: working out the logic flows in assembler and breaking them out so that they can be translated into a higher-level language. I've always thought that this type of government work should be open to bids from anyone . 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. The fact that only ver…

> 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 agree, it's a thorny technical issue, for sure.

My thinking is that the issue isn't actually technical, but one of risk management, and that's something that markets are very good at dealing with. I would guess that there would be quite a few companies out there willing to step in and certify/insure code quality, for the right price.

Of course, DOD and other more sensitive systems are a completely different animal with respect to risk, so this wouldn't necessary apply there.

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

#216

Post by TimJYoung »

empath75 wrote: post #173
TimJYoung wrote: post #7

Wow, what a cool project to work on: working out the logic flows in assembler and breaking them out so that they can be translated into a higher-level language. I've always thought that this type of government work should be open to bids from anyone . 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. The fact that only ver…

That’s actually not true. I work for a fairly small contractor (a few hundred people) working on a fairly large government contract. It started with a handful of people when the company was a fraction of the size.

I'm very happy to be proven wrong. I must admit that I know very little about the process, other than what I've read, and what I've read hasn't been positive. But, I'm sure that small, successful projects aren't talked about nearly as much in the press as large, unsuccessful projects, so it could simply be bias in what I'm reading.

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

#217

Post by s73v3r_ »

BookmarkSaver wrote: post #190
s73v3r_ wrote: post #178

Earlier quoted context omitted.

I think the comparison is quite apt. Shakespearean English is an ancestor of today's English, much like assembly languages are the ancestors of today's languages. Shakespearean English is grammatically correct, much like this assembly code is, presumably, correct in doing what it needs to do. And, most pertinent, almost nobody speaks in Shakespearean English, and fewer and fewer people are comfortable working with it…

I don't think it addresses one of the most important aspect of assembly, though, which is it's strict, functional/feature inferiority to modern languages. It isn't just old and forgotten, its very style and function is extremely limited in comparison. Shakespearean English is just about as functional of a language as modern English (ignoring the vocabulary for things that didn't exist back then), which can't be said…

"I don't think it addresses one of the most important aspect of assembly, though, which is it's strict, functional/feature inferiority to modern languages."

I think that's addressed in the, "No one really uses it anymore" part.

"Shakespearean English is just about as functional of a language as modern English (ignoring the vocabulary for things that didn't exist back then), which can't be said about assembly."

I would disagree. Arguably, the main function, if not the only function of English, or any other human language, is to express ideas. Shakespearean English being not commonly used, and many of the colloquialisms and terms used not being in use anymore would make that function more difficult. As an example, I'd use the "Romeo, Romeo, wherefore art thou Romeo?" line. To most people, that would be Juliet asking where Romeo was, but it's not. It's her asking why Romeo had to be who he was, which was a Montague, the rival/enemy of her family.

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

#218

Post by slededit »

tzs wrote: post #204
slededit wrote: post #83

Earlier quoted context omitted.

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 3…

At that point you might as well embed an emulator with a facility to call to/from plain java code. Then you could gradually move things over as needed.

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

#219

Post by TheSoftwareGuy »

bpicolo wrote: post #34
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…

Seems unlikely that they can hire many cross functional tax-law-programmers. You integrate teams so there are experts on both.

Maybe, but my line of thinking is that it could be easier and better to teach tax law specialists a little bit of Java, than the other way around
Post reply on HN