201–210 of 211 posts
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.
Should it be written in Go, or Rust?
Can the USDS assist here?
Earlier quoted context omitted.
>I think you're over-estimating the amount of data involved. A better analogy would be if you were an airline and kept upgrading airplanes before they were needed. Airplanes (especially private ones) fly for decades and decades. No one is suggesting that the IRS systems weren't maintained. Obviously they were since they exist on virtualized hardware.
Airplanes get upgraded all the time - fresh seats, newer gps tech, etc. Software systems like this get “mainenance” of the bare minimum sense - think a new battery after the original is dead.
Earlier quoted context omitted.
Only if you're driving forwards. The crash test rating arms race gave us vehicles we can't see out of then we backed over so many kids that the federal government mandated a rear camera in everything.
I want to think that’s just consumers’ preferences shifting towards SUV and Crossover cars that necessarily have poor rear visibility. Nothing about having a good rear crumple-zone leads to restricting the size of the rear window or placement of the C-pillars.
Crossovers typically have equal or better rear visibility to the car they're based on because the higher seating position means you can look down at a steeper angle greatly reducing the maximum distance at which a kid height object is not visible to the driver.
Earlier quoted context omitted.
That would be a huge exploit/privacy risk.
How would it be a privacy risk, unless, the data files were included/embedded in the source code repo?
Earlier quoted context omitted.
That would be a huge exploit/privacy risk.
Is that why Google's and Amazon's linux kernels are constantly being exploited?
Earlier quoted context omitted.
I heard that COBOL programmers do pretty well because they are a rare commodity serving expensive industries.
If you're happy with working with something that destroys your brain and makes you useless to any other software technology developed in the last 20 years be my guest.
To me, it's the cool-app-of-the-month-that-harvests-private-data-off-peoples-devices that is brain-killing.
Earlier quoted context omitted.
>How do we separate business logic in a self-contained way that can be independent of hardware and (from a certain level) software? Come up with programming languages with limited domain specific functionality that don't allow you to do funny machine specific things. (or even ordinary things like pointers) Use the restricted languages for business logic and have a second language to do the plumbing. Or just target a…
So all critical software in Python or JS? Not so sure about that. I get the idea but think having strict code guidelines might be more effective than choosing a more restrictive language.
Earlier quoted context omitted.
You're assuming the target audience to only comprise of subject matter experts. This article is perfectly ok for 90% of the tax paying population that works outside tech
And maybe even better for those 90%. Introducing more technical terms (e.g. specifying the Assembler used) makes it less readable for anyone without the domain knowledge. Often, when trying to explain something to the broad public, making it inaccurate is a necessity.
In other words, the authors are speaking with authority about something they demonstrated ignorance of by improper use of an article and they went out of their way to use language that would lead a non-technical reader to conclude the failure that occurred was a result of 60 year old code when in reality it was due to 18 month old hardware.