Java? Hope they don't need an unsigned byte.
Working with a mix of signed and unsigned in java is a nightmare.
The IRS’s Effort to Convert Its Assembly Codebase to Java
51–60 of 224 posts
Re: The IRS’s Effort to Convert Its Assembly Codebase to Java
#52> Assembler is like Shakespearean English. It’s dated. A shrinking number of people can deal with it. But it’s also elegant and highly functional. What is considered elegant and functional about assembly?
> Tao of Programming 8.3
> There was once a programmer who wrote software for personal computers. "Look at how well off I am here," he said to a mainframe programmer who came to visit. "I have my own operating system and file storage device. I do not have to share my resources with anyone. The software is self-consistent and easy-to-use. Why do you not quit your present job and join me here?"
> The mainframe programmer then began to describe his system to his friend, saying, "The mainframe sits like an ancient Sage meditating in the midst of the Data Center. Its disk drives lie end-to- end like a great ocean of machinery. The software is as multifaceted as a diamond, and as convoluted as a primeval jungle. The programs, each unique, move through the system like a swift-flowing river. That is why I am happy where I am."
> The personal computer programmer, upon hearing this, fell silent. But the two programmers remained friends until the end of their days.
And I have heard cool things about mainframe assembly programs (at least on z/TPF). Like a system to do code upgrades without hardly any downtime by pausing the VM, doing brain surgery on it, then resuming it.
Re: The IRS’s Effort to Convert Its Assembly Codebase to Java
#53Earlier quoted context omitted.
I would disagree. On of my first jobs was porting assembler to C for a paging switch. The assembler was well written and well documented. The task was slow, hard and painfully boring. It took months to get every function to be a perfect match.
Did you manually convert the assembler, or automate it ? With regard to manual conversions, I'm with you 100% - no thanks. :-) But, my understanding is that the bulk of the work done in this case was done by a conversion tool that was designed and developed by a group of 8 people led by the gentleman referred to in the article (Jian Wang). The conversion tool project was the work that I was referring to in my comment…
Yes, manually. I missed that distinction, building the tool could be fun, but verifying it works would be a huge pain. Shouldn't be too hard to write test cases for tax code.
Re: The IRS’s Effort to Convert Its Assembly Codebase to Java
#54If you machine translate assembler to Java won't you still end up with confusing code?
Re: The IRS’s Effort to Convert Its Assembly Codebase to Java
#55Just imagine if this new system was converted to groovy or scala. That would be pretty amazing.
Are people writing new non-Jenkins Groovy code in 2018? What's the use case? Legitimately curious. My experience with Groovy is always frustration and I liken it to the Coffeescript of Java.
Grails, POCs, Ratpat (ok danveloper.. we get it, that exists), Spock tests
Why do you regularly get frustrated with groovy?
Re: The IRS’s Effort to Convert Its Assembly Codebase to Java
#56Wow, 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…
Rather than transcode assembly to a higher-level language. It's better to nail down all the functionality the assembly program provide and re-implement them in the higher-level language. Write language independent tests against the old code and re-run the tests against the new code to make sure things are working feature for feature and bug for bug.
Re: The IRS’s Effort to Convert Its Assembly Codebase to Java
#57> Assembler is like Shakespearean English. It’s dated. A shrinking number of people can deal with it. But it’s also elegant and highly functional. What is considered elegant and functional about assembly?
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.
Re: The IRS’s Effort to Convert Its Assembly Codebase to Java
#58I feel like if the IRS had a software provider that was privatized, this would not be an issue.
Re: The IRS’s Effort to Convert Its Assembly Codebase to Java
#59> Assembler is like Shakespearean English. It’s dated. A shrinking number of people can deal with it. But it’s also elegant and highly functional. What is considered elegant and functional about assembly?
For that matter, I take issue with the idea that Shakespearean English is any more elegant or functional than contemporary English. I would consider the poorly standardized spelling and, to an extent, grammar, to be pretty damn inelegant!
Re: The IRS’s Effort to Convert Its Assembly Codebase to Java
#60> Wang was working under streamlined critical pay authority the agency has had since its landmark 1998 restructuring. It gave the IRS 40 slots under which it could pay temporary, full-time employees higher than GS rates. Former Commissioner John Koskinen pointed out Congress did not re-up this authority in 2013, despite his entreaties to former Congressman Jason Chaffetz’s Committee on Oversight and Government Reform…
"1998 restructuring. It gave the IRS 40 slots ... Congress did not re-up this authority in 2013"
That's 15 years of "streamlined critical pay" authority. And it appears that some number of these slots continued to exist until recently. Two decades of special authority to modernize this software, and nothing to show for it, except perhaps some patents...
At some point you have to cut your loses.