Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Modern Compiler for the French Tax Code

arxiv.org

Post reply on HN
Print view View original

101–110 of 136 posts

Re: A Modern Compiler for the French Tax Code

#101

Post by sjy »

mywittyname wrote: post #56
tester34 wrote: post #40

I've been asked to write parser of _my_country_law_ and something that's capable of doing diffs and putting it together (diff+original=>newest version) docs without knowledge in that domain 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 feel like legislation is a field that would benefit a great deal from the progress that software engineering has made in a number of fields. 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 rule…

The current buzzword for this is “rules as code” and many governments are exploring it. You’re right that it is particularly relevant to complicated financial laws like the tax code, and necessarily has been done in a limited way by tax software for many decades now. I am skeptical that this technology can meaningfully assist us in resolving contentious legal questions – it’s more about generating wizards that can help you navigate a 1,000 page tax statute by only showing you what’s relevant to your problem.

Re: A Modern Compiler for the French Tax Code

#102

Post by semi-extrinsic »

e12e wrote: post #96
semi-extrinsic wrote: post #82

Earlier quoted context omitted.

The COBOL part is from memory. I'll have a look to see if I can find a copy floating around somewhere. 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...

I did find an awkward source that lists the 2017(?) COBOL code for the tables - the core program seems to be last updated 1993 (Norwegian only) : https://docplayer.me/38761458-Beregning-av-forskuddstrekk-in... > IDENTIFICATION DIVISION.  PROGRAM-ID. FT7P200T. AUTHOR. PER J. RISTUN. DATE-WRITTEN. NOVEMBER 1993 ----------------------------------------------------------------  * BESKRIVELSE : PROGRAMMET BEREGNER FORSK…

This is the one!

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.

Re: A Modern Compiler for the French Tax Code

#103

Post by sjy »

contingencies wrote: post #95
smarx007 wrote: post #50

Earlier quoted context omitted.

> law-as-code is a bad idea because its "dynamic"/"always changing" 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 t…

Yes, in the current system it's shifting goalposts. That is a bad system. 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 bey…

The last century has seen a huge increase in the quantity of law that is written out explicitly in statutes [1], rather than being worked out on a case-by-case basis according to the common law method. This is an attempt to “improve the language” as you have suggested, but it has not made the law easier to comprehend. Detailed statutes make it harder for lawyers to build up a coherent picture of the entire legal system, because there’s a much greater risk that a solid argument based on general principles collapses due to a specific statute that the lawyer has never heard of.

[1] https://www.gov.uk/government/publications/when-laws-become-...

Re: A Modern Compiler for the French Tax Code

#104

Post by eecc »

mywittyname wrote: post #56
tester34 wrote: post #40

I've been asked to write parser of _my_country_law_ and something that's capable of doing diffs and putting it together (diff+original=>newest version) docs without knowledge in that domain 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 feel like legislation is a field that would benefit a great deal from the progress that software engineering has made in a number of fields. 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 rule…

IMHO we shouldn't define the problem in terms of reducing legislation into some computer language or schema; indeed the effort should be in describing and linking the terms into a graph with consistency validation rules and shape identities.

Re: A Modern Compiler for the French Tax Code

#105

Post by Taniwha »

valuearb wrote: post #60

I remember when the US tax code was going to be simplified so that an entire tax return form could be printed on a post card.

Here in NZ we got rid of almost ALL deductions the tax system is so simple that almost all people with one job pay exactly the right tax through employer PAYE (as someone who runs a small company I do my PAYE with 1 line of spreadsheet formulae, it's easy).

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

Re: A Modern Compiler for the French Tax Code

#106

Post by sjy »

MaxBarraclough wrote: post #15
secondcoming wrote: post #4

Translating legal texts to mathematical form is very interesting. It could decimate most legal jobs if a lawsuit can be converted to mathematical form and then 'executed' against the laws that are also in mathematical form. You get your judgement and the explanation as to how that conclusion was reached, all automatically. It could even cause headaches if contradictions in legal judgements are detected. It all relies…

It's not possible to reduce all lawsuits to compact formulae. Part of the legal profession is in interpreting old laws in the modern context, for instance, which would take something close to a general AI. More broadly, reasoning about legal edge-cases needs a sophisticated understanding of the law and of the world. Also, jurors can't be replaced by software, as they must be 'peers' by definition. I imagine it would…

Work is being done on this – here’s some in the human rights context: https://link.springer.com/article/10.1007/s10506-019-09255-y

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.

Re: A Modern Compiler for the French Tax Code

#107

Post by 908B64B197 »

denismerigoux wrote: post #43
ethbr0 wrote: post #42

Earlier quoted context omitted.

The nearest I've been able to articulate this is lack of overlapping skillsets & departments' tendencies to hire people who look like them. 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…

Hi, OP here :) I've come to the same conclusion about programming language creation. However, for a very large organization, it makes sense to have a team in charge of language tooling (see Dropbox/Python, Facebook/Hack/Flow, Apple/Swift). Which is why I'm trying to convince the French state that they should have such a team of permanent people.

The issue you'll bump into is attracting the same caliber of talent.

Compare the offers from Dropbox, Facebook and Apple.

Re: A Modern Compiler for the French Tax Code

#108

Post by akx »

alextheparrot wrote: post #23
ghaff wrote: post #19

Earlier quoted context omitted.

I'm not near the space any longer (in a former life, the healthcare industry was a big customer of our computer systems). But a significant portion of healthcare in the US used to use a proprietary language called MUMPS. https://en.wikipedia.org/wiki/MUMPS

Epic has been trying to move on for years, or so a recruiter told me half a decade ago. Their job posting now describes “Using leading-edge technologies and languages like JS, TS, and C#”, though I wouldn’t put a bait and switch past them.

Yeah, well, they have a thing called TS2M, referred to e.g. here... https://www.reddit.com/r/epicsystems/comments/9pmsjj/ts2m_in...

Re: A Modern Compiler for the French Tax Code

#109

Post by eecc »

vishnugupta wrote: post #31

During one of those rabbit hole journeys I discovered that Dutch Tax authorities use MPS, a DSL creation language/tool by JetBrains [1] 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. [1] https://www.jetbrains.com/mps/documenta…

They do? That's bloody awesome... there's something to this country I love, despite the bad weather and worse food :)

Can you share the resources you found?

Re: A Modern Compiler for the French Tax Code

#110

Post by walshemj »

mywittyname wrote: post #56
tester34 wrote: post #40

I've been asked to write parser of _my_country_law_ and something that's capable of doing diffs and putting it together (diff+original=>newest version) docs without knowledge in that domain 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 feel like legislation is a field that would benefit a great deal from the progress that software engineering has made in a number of fields. 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 rule…

This sounds easy until you actually get to grips with how parliamentary procedure and law making actually works.

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

Post reply on HN