Was this based on the work one IRS engineer did?
https://federalnewsnetwork.com/tom-temin-commentary/2018/01/...
edit: Added link to patent application.
https://federalnewsnetwork.com/tom-temin-commentary/2018/01/...
edit: Added link to patent application.
> [Wang] says he applied to become a GS-15 or Senior Executive Service member so he could see through the assembler-to-Java project. But his approval didn’t come through until a week before his employment authority expired.
They lost a guy responsible for software that could save taxpayers how much -- tens of millions of dollars? More? All because they couldn't pay a guy a GS-15 salary, which translates to $100k-140k.
Man, people are really dumb about paying programmers well. They'd rather see a project go off the rails than pay someone (still slightly below) market rates.
Also:
> In many ways, assembler is still excellent for this application. Milholland said of the code, “The assembler is well written. It’s incredibly efficient and effective.” But a shrinking number of people understand it. And it’s not optimized for the online, transaction mode to which the IRS needs to keep moving. Java, relatively inefficient as it may be, is the current standard and has legions of people who know it.
That's like arguing mixing concrete by hand is "more efficient" because doing so allows you to be more frugal with concrete.
No, that's more like saying mixing concert by hand starts to become attractive because there's only one guy on Earth who knows how to operate a cement mixer. The alternative is crap, but it's easy to find people to do it.
This is the reason that makes me believe Go is going to be the new Java: a language with good enough performance, lots of safeguards preventing sloppiness to break, and a very very flat learning curve.