I've added an issue to track that based on your feedback:
https://github.com/ustaxes/UsTaxes/issues/458
And another issue about floating point:
https://github.com/ustaxes/UsTaxes/issues/457
I have doubts about the floating point issue just because all values on the tax forms are calculated using floats and then rounded to the nearest whole dollar. But if there's even a possibility that an intermediate calculation could flip a x.49 to a x.50 and change the rounding, then I agree we should switch to a library.
About the contributor guide, we just tried to write it to be as welcoming as possible to new contributors. With respect to "'ask in discord' for the actual content of the tax calculations", I'm just not sure what you mean. That document isn't really relevant to tax calculations. We will give the document another look though based on your feedback.
https://frontstuff.io/how-to-handle-monetary-values-in-javas...
I guess that's true if the only kind of contribution one wishes is for React or docker or rust-lang fixes, but the issues list currently contains "schedule E" and "HSA 8889" which don't sound like React or "general purpose" software contributions: they sound like changes or contributions to the tax calculations
If someone on HN has a passion for fixing those items, which section of the contributing guide tells them how to code up "schedule E" in a way that is going to be accurate and have its PR accepted? Saying whether new contributions require an accompanying test, and the testing strategy, seem also just absolutely beyond critical to me for a tax calculation system
Maybe all of these are, in fact, covered in discord. I grant that I'm just not a "hop into chat" kind of person, because I find it chaotic, the search is usually oppressively terrible, and it means someone needs to be available at the same time that I have the question
I figure if M:TG can be implemented, surely the tax code can, too, even if it requires an "expert system," or machine learning, or NLP or something other than 1,500,000 lines of C++ or whatever TurboTax is written in
---
Actually, that's also an interesting question: surely the IRS doesn't rely on an army of people with calculators and pencils to verify said returns, so I wonder if a well placed FOIA request would cough up their COBOL source code they use?
This is written in TypeScript.
As with most everything the problems with why it hasn't been done are unrelated to someone not selecting the "right" language to do it in.
> Actually, that's also an interesting question: surely the IRS doesn't rely on an army of people with calculators and pencils to verify said returns, so I wonder if a well placed FOIA request would cough up their COBOL source code they use?
As mentioned is has to do with lobbying from the major tax companies. The "Free File" program was created out of an agreement the IRS wouldn't create such software usable by folks if the tax companies offered their existing software to most that needed it. https://www.propublica.org/article/inside-turbotax-20-year-f...
Joking aside, I think the commonality between collectible card video games and legal code is the notion of "code as data." The record that tracks, say, a Shadowverse or MTG card (not going to mention the other obvious example, especially not today), associates it with artwork, ensures that display logic and other-card-interaction logic is normalized with minimal duplicated data, allows it to be hotfixed, tracks its state through various QA stages, automates fuzz testing with many combinations of other cards... all that has analogies to what would be needed here.
It's a rule engine where every field is a node in a directed graph (of course it's the tax code so it's not an acyclic graph, who are we kidding) but there are ways to analyze that. But, the same way a AAA game studio has ways to manage semi-trusted contractors (and, it would seem, even less trustworthy creative directors) and ensure quality at scale, one could imagine a crowdsourced system for rule verification. The "product" is less a tax form filling system and more of a distributed version control system and CI platform. You solve that, you solve a lot.
Another part is that it's hard to program them in a sane way because the rules are arbitrary. It's possible to code how the rules are, but it's impossible to guess how they'll change in the future. Two things you assumed would never interact might need to interact in the future. Two things you thought would never stop interacting might suddenly stop.
I'm not an accountant, but in the Magic world, you would assume that the turns go in a set order, right? Nope, there are cards that reverse the order of turns permanently. You would assume that a player always controls their own turn though. They don't though, there are cards to let you take someone else's turn. There are also cards that let you play the cards out of other peoples' hands.
I looked at coding it, and it turned into spaghetti pretty quickly. Everything has to have ways to interact with everything else, and testing becomes incredibly difficult because of the sheer number of ways these things can interact. And it's hard to make even the most basic of assumptions because they're liable to change at any point. There are no "laws of physics" that at least define a set of possibilities.
They already have experience creating tax software so it seems like an obvious choice to outsource to.
Otherwise, I, too, can just make up 1.45 numbers: https://github.com/ustaxes/UsTaxes/pull/422/files#diff-76e87...
The contributor guide spends a lot of words specifying commit format, and then just says "ask in discord" for the actual content of the tax calculations :-( https://github.com/ustaxes/UsTaxes/blob/master/docs/CONTRIBU...
To come back to a technical discussion, I thought the best practice was not to use floating point numbers for currency, and that goes "double" for JS's `Number` which like everything else in JS is kind of loosey-goosey about accuracy anyway: https://github.com/ustaxes/UsTaxes/blob/v0.1.4/src/irsForms/...