A Modern Compiler for the French Tax Code
arxiv.org
arxiv.org
This interesting. When it comes to legacy code we think of COBOL and FORTRAN most of the time, but probably there is a huge amount of even more exotic code out there that does its duty day in day out.
They switched to Java in 2018-ish - and to Github instead of a random FTP server.
Doing your taxes has also been a no-op for many people the past decade or so. You don't do anything except read the tax report, unless you spot some mistakes or items missing in the report that was autofilled by the government, then you can go into the web form and submit the amendments necessary.
A buddy of mine retired rich after creating property tax administration systems. They only had a few client counties.
They'd just about rollout new system updates before the next wave of tax code revisions. Never ending work.
Sounded like living hell. I couldn't do that kind of work and stay sane. But he seemed to enjoy it.
Ed: ah, same country https://news.ycombinator.com/item?id=25210009
A little unfortunate that we threw it out.
Edit: the transition appears to be more like 2016, and one of the commits then refers to a file generated from COBOL: https://github.com/Skatteetaten/trekktabell/commit/5181d86c5...
> IDENTIFICATION DIVISION. PROGRAM-ID. FT7P200T. AUTHOR. PER J. RISTUN. DATE-WRITTEN. NOVEMBER 1993 ---------------------------------------------------------------- * BESKRIVELSE : PROGRAMMET BEREGNER FORSKUDDSTREKK FOR ÅR 2017 * (...)
If memory serves, they updated the program for each year (I guess only numerical constants and small rule changes), but they probably didn't update the source in the documentation.
(I just googled GP's email address (it's in their profile).)
Here our income tax declaration is very simple, the tax office already knows how much salary we have earned, and there aren't many deductions, so most people either don't have to file taxes at all, or just click next a few times and get their tax returns after a week or so. For 90% of people it takes less than 5 minutes.
I always thought it'd be easier to use an emulator and keep using the old stuff. Then over time whittle the code base down to just the business logic.
Including for new developments.
after seeing sample doc I've estimated it on something like 1 week of work (XD)
month later I've been crying and having like 20-30% done
this shit has been so sensitive (insanely error prone) and debugging was time costly. I think I didn't spent enough time on thinking about its architecture, but on the other hand my experience was pretty small with this stuff
easy & fast to test and reliably
have solid abstraction over original documents
have solid abstraction over operation (e.g Article 5's meaning is changed)
_____________
project died because it was needed "fast" (in that time there was very specific peroid of changes in law) and we weren't getting to the viable version fast enough
It's already evolved somewhat into a DSL. With some nudging and technical leadership, I suspect that we could move it over entirely into a format that can be readily parsed, tested, and version control. The tax code is especially well-suited to this, because it's a lot of rules and math formulas.
In fact, I bet most tax software probably does something very similar to this.
That's not true. Agencies that do rulemaking have to provide justification for why they're enacting or repealing particular regulations, otherwise those regulations can be struck down as capricious. This is a major problem the Trump administration had: a lot of their attempts to rollback Obama's policies or enact new ones foundered on the ability to provide this justification.
...in the court of law. Someone had to go and sue the administration. When they issued the policies, they simply provided no meaningful justification. You're proving my point.
For example last year I was on a SOC (Standing orders committee) for a 3.5 day conference with 600+ delegates.
We had 120 motions submitted working out Consequentials if motion 15 passes motions 16 99 and 120 fall is non trivial.
We also had to do compositeing of 20/21 motions on one topic which where all worded slightly differently and had slightly different effects took 4 of us about 2/3 of a day just for that.
Another example is say the various legal documents for pensions a choice of a different two letter word can lead to years of legal arguments - the difference between CPI and RPI
Cornell Law has providing version control releases of the federal laws for some time for free, and Lexis and their competitors have been doing the same for decades for commercially.
I ask because my state's legislature has a staff that reviews proposed legislation and then maintains the revised official laws. If I was tasked with doing diffs, I'd first interview them, try to make their jobs easier.
Is this deduction before or after your AGI, whats the maximum % of AGI that it can be, does taking the deduction lower your AGI and thus the max percentage of AGI that it can be?
It makes me wonder, why haven't DSLs caught up? Their claim that it allows developers spend more time implementing the business logic makes sense. But somehow that promise hasn't been realised. I'm curious to know from those who tried DSLs.
The kind of person who (a) lives in business problem land & (b) is proficient in programming language design (even guided DSL generation)... doesn't exist. At least not in hireable numbers.
And those that do are buried deep in the guts of consultancies, who can afford to pay them way more than customers can.
It's a shame, because it results in suboptimal software. And suboptimal tooling available to the devs that do work in that space.
The best solution I've seen are products that lower the knowledge barrier of entry (at least for creating a proof of concept) + designing for non-programmers as your primary users.
The only advice I'd give would be to lean hard on finding, maturing, and then advertising end-user champions.
Cross-department / -traditional boundary products are frustratingly difficult to push top-down, as the leader of the space that "owns" the product (i.e. IT) doesn't directly see the value, because they're not the end user (business).
What mostly work for me was being as loud as possible with open-attendence educational events, continually taking meetings from interested areas, and then mentoring developing teams.
The goal is to help them create a killer product using your product, such that (highly-placed leader on their side) talks to (your leader) in glowing terms about your product. And that usually happens because your product helped them get a win that moved an important metric to them.
Hint: Ask them about things they've always wanted to do, but couldn't because it was technically impractical. There's probably at least one diamond in there that would be "easy" with your product.
Hint2: Think more broadly about the kind of thing you're trying to do, and get your team in that area. I've worked under CFOs as often as I've worked under CTOs, because "saving money" is near and dear to the former.
(Adapt as necessary to how French government works. Good luck!)
I tend to think that platform/framework teams within a large orgs should be run as a B2B SAAS, at least with that mindset.
Also, if a platform team isn't run well, it ends up being the first one on the chopping block during layoffs. Uber laid off an entire developer-platform team earlier this year. One casualty was the Screenflow team, a promising product that didn't gain wider adoption due to terrible marketing/evangelism.
What features should you work on next? The things your users are asking for at your touchbases.
There's a time and place for top-down, but it works best when there are few edge cases. Platform work tends to be a normal distribution with the usual number of "Oh. We never thought anyone would want to do that" tails.
Compare the offers from Dropbox, Facebook and Apple.
IMO, the problem is our languages are unnecessarily complicated. they are all linearly parsed BNFs, and you don't need any of that. I think things will start changing big time.
That being said, my favorite ecosystem in the traditional DSL world is ANTLR, and I'd highly recommend Terence Parr's books on the field if you are interested.
I'm just a grammar mechanic, so I don't really grok the underlying theory or use the right word for this stuff.
"The Definitive ANTLR 4 Reference" is absolutely the most understated title I've ever seen in a book. It's really more like "The Book That Will Change How you Look at Programming Languages Forever"
IMO anyway. I guess it depends on how much you've been exposed to parsers and grammars and compiler compilers already.
Can you share the resources you found?
You will find a decent info to get started here[2]
[1] https://www.jetbrains.com/mps/ [2] https://www.jetbrains.com/mps/concepts/domain-specific-langu...
To have a 'proper' DSL I reckon you need two things, and understanding that a thing can and should be broken out into its own sublanguage, and the ability to do so. The first takes a certain kind of nouse, or common sense. The latter requires knowing how to construct a parser properly and some knowledge of language design.
Knowing how to write a parser is not particularly complex but as the industry is driven by requirements more of knowing 'big data' frameworks rather than stuff that is often more useful, well, that's what you get, and that includes people who try to parse XML with regular expressions (check out this classic answer <https://stackoverflow.com/questions/1732348/regex-match-open...> Edit: if you haven't seen this check it out cos it's brilliant).
I think this reflects the fundamental problem in software development of the market's not knowing what's actually needed to solve real business problems.
++++
Edit, some reading material
https://www.amazon.co.uk/Language-Implementation-Patterns-Do...
https://www.amazon.co.uk/Definitive-ANTLR-Reference-Domain-S...
https://www.amazon.co.uk/yacc-Nutshell-Handbook-Doug-Brown/d...
They're all worth investing the time in.
At least, that's the right way to name things in code.
As a side-note, the source code appears to have moved here: https://gitlab.adullact.net/dgfip/ir-calcul
As most AI, it's regex and ifs all the way down.
This made me laugh way more than expected, mostly because of how true it is.
application : pro, batch , iliad,oceans ;It could even cause headaches if contradictions in legal judgements are detected.
It all relies on the conversions to mathematical form being done correctly though which, given that some laws can be intentionally vague, may be impossible.
https://theconversation.com/csiro-wants-our-laws-turned-into...
https://research.csiro.au/bpli/our-research/reasoning/
https://people.csiro.au/G/G/Guido-Governatori
They are using https://en.wikipedia.org/wiki/Deontic_logic and https://en.wikipedia.org/wiki/Defeasible_logic describe laws in terms closest to how it's done in the legal community.
Can't find a link but they codified some parts of the Australian import duties laws that we went through in a workshop of theirs that I had a chance to attend.
The first argument is nonsensical (computers are great at changing data: in fact way faster and more accurate than humans, having the capacity for things like single source of truth, change logs, peer consensus, and dynamic versioning while preserving historic versions automatically... and also better at publishing it, analyzing it, and documenting it).
The second argument is an outright straw man fallacy. Who cares if some laws require interpretation. Just write MAY instead of WILL (like RFC language) to make it clear the judge can decide, then provide statistical information regarding past case law. Nobody is saying "fire all the judges", they're just saying make the law clear. Right now it's not clear, and it's a big problem.
Refugee? Read up to date law in your language, automatically. Business? Determine what is required by law in order to execute a transaction. Human? Determine what you are and are not allowed to do in some field (like architecture, driving, sailing, pet walking or rock collecting) without being fined.
But that is not how law works. A judge is generally expected to interpret the law because we cannot expect someone who wrote the law to have predicted all possible things, especially those that did not even exist when the law was written.
It's (often) not close to a machine-interpretable spec, but a to visual mockup, to stay in the software area.
For example, you may have a law to forbids euthanasia. Does it also extend to assisted suicide? What if the dying person can't physically trigger their own death? What if assisted dying is illegal here, but someone takes the patient to the neighboring country?
Also, I hardly believe "read up to date law in your language" is possible, there are entire legal concepts that do not exist in different jurisdictions, or literally the same expression may mean different things ("voir dire" for example).
It's good to attempt formalizing things, but I don't think this is a strawman.
I don't think it was meant in classical terms of an SQL UPDATE. It was meant in a way that a new rule may affect the application of an existing rule. Academically speaking, it makes reasoning non-monotonic. This is exactly why https://en.wikipedia.org/wiki/Defeasible_logic is proposed.
> The second argument is an outright straw man fallacy.
I think they are trying to codify the laws in logic _without_ changes to the law.
[Edit] The journalist also failed to read up on the basics of deontic logic and defeasible reasoning: "The law says cars must drive on the left in Australia. But what if they have to cross the road to avoid hitting a child?"
You cannot completely successfully codify something that is based on the vagaries of wishy-washy language, nor specific legal concepts like the intent of regulations or the context of prior judgements. Therefore, improve the language: don't give up!
Imagine if latitude and longitude weren't invented because "sorta over there a few days sail beyond the cape" was too hard to quantify. This is the same ridiculous argument. It just so happens that there are also a vast number of ingratiated rent seeking and powerful people and corporations interested in the status quo: literally all of them.
I believe that as engineers and as optimists within the greater human endeavour, over time in all fields we should seek to create means of trust and means of precision: in our measurements, in our communications, in our analyses, in our references and in our collaborations.
We don't need to fire all the judges. But maybe 90% of the solicitors and standard procedural lawyers, a large part of whose job is explaining to the average citizen what exactly is the done thing in some particular area or how exactly they can expect to be treated the hands of a system that cannot otherwise explain itself.
Also, in terms of community governance if it becomes crystal clear that a law is being abused through increased fidelity in the logging of police actions brought about by such a system, then the law can more rapidly be identified and repealed.
[1] https://www.gov.uk/government/publications/when-laws-become-...
I remember hearing an anecdote about researchers who tried to formally specify the benefits system of some European country, and they found that the system was slightly non-deterministic, in the sense that the outcome for the citizen would depend on which order various government departments processed the various forms that the citizen used to enrol into various programmes they were eligible for.
It makes me wonder if these mathematical formalisations should support some kind of fuzzing, to check that entities doing things in slightly different orders (or earning slightly more/less) don't produce dramatic changes in outcome.
I imagine it would be much easier to build a system to roughly estimate the odds of a lawsuit being successful, inputting salient features of the case and running the numbers, without deep reasoning about the particulars. I don't know if work is already being done on this but I wouldn't be surprised. A lot of money must ride on knowing which corporate law battles can be won.
But the outcome of high-stakes commercial litigation is much more complex than “win or lose.” Most cases settle, so the ones that result in published legal judgments which can be fed into a machine learning tool are an unrepresentative minority. Participating in this kind of litigation also costs millions and attracts public attention, leading to innumerable second-order effects (eg. public relations damage, law reform) that are hard to predict and may be more significant than whatever specific legal decision a judge makes. So being able to put a numerical probability on the legal opinion “we think the company has a good chance of winning this case” may not be that helpful.
Ultimately, I don't see law being automated. As others have pointed out, most cases that go to court are all about interpretation and establishment of the circumstances (did events X, Y and Z happen), interpretation of the law (does law F mean that event X was illegal, and is event Y a mitigator or irrelevant?) and, more elusively, impact (how serious was X?).
What this doesn't mean, though, is that there aren't tools that can't be used in the creation and management of law. If we have a simple dependency tree of documents and sources, we can trigger a review of downstream documents if a document is changed. We can statically check some aspects of the document, like a Legal IDE that would present itself more like an advanced spellcheck. Meta rules can ensure consistency, add in support for in-line reading (include a definition next to a paragraph even though it is defined elsewhere).
Probably the closes thing you'll get to an 'automated' system would be for the 'process' that is currently done by administrators to be partly or fully automated. When charges are brought, a court date is automatically booked. When a judgement is made, a court report is generated, prison alerted etc etc.
Basically, everything that people in tech think should be automated, shouldn't be, and all the things technology people think shouldn't exist should be automated.
I agree. Very interesting. Realistically, paperwork & bureaucracy is an ideal target for automation. That said, every input that you feed an algorithm is legally debateable... Structuring your inputs to be both legal and optimal is more storytelling than mathematics. There's enough play in these "subjective" parts that results could be anything.
Still, having a major algorithmic in the mix changes the game.
The fact is, that while PCs have been (a) on every desk and (b) paperwork efficiency machines for the last 30 years... the total number of legal/accounting/hr/admin jobs has increased in this period.
The effects of technology/efficiency on "clerical" work is not predictable in the way it is on factories.
I have no idea what would be in it for Common Law countries. Perhaps they'd be more driven towards using data mapping techniques to lay out networks of heterogeneous legal stuff (jurisprudence etc.).
The law will go from written natural language to executable computer programs (formal languages).
However a change of this mangnitude cannot happen quickly, (and might even be impossible to do peacefully).
Abusing the "software is eating the world" analogy, we ain't seen nothing yet. Software is just barely opening its mouth.
Even ignoring the subtleties of the real world that the ̶l̶a̶w̶ edit legal system must cope with, nuts-and-bolts legal concepts like mens rea can't be mapped to algebraic expressions.
[0] https://arstechnica.com/tech-policy/2020/06/indiana-supreme-...
The projections were the basis for advising the client how to best manage their finances.
The advisor model could request an optimisation of how to best allocate the assets and liabilities over time from a mixed integer programming model built with GAMS. The latter optimisation model was not exact but it could generate close-to-optimal strategies for e.g. pension savings, buying houses and how to best spend the savings after retirement. The best strategies were then fed back into the exact model, evaluated and presented to the user.
It requires a pretty complex tax system to really generate a lot of value for the clients so its value was lower in the neighbouring countries that had separated their social systems more from the tax system.
https://blog.merigoux.fr/en/2019/12/20/taxes-formal-proofs.h...
This means most people don't need to file, if you want to it's a 1-2 page web form, and, starting last year, the IRD will do it for you anyway and directly credit your refund (with interest) to your bank account without you asking
We have no tax on capital gains (we should, it badly distorts our markets, leaves too much money in real-estate).
The idea was that you don’t have some rich paying the top rate of 39%, and some paying near zero (cough, cough, Mr. Trump) due to a large discrepancies in deductions.
Gotta love the sense of humour.