> Imagine we had a versioned database with all the laws from all countries where one could compare them side by side. We could begin to understand the mood or spirit of each effort.
It would be good. There have been some attempts at source code style revision management for statutes (such as https://www.lafabriquedelaloi.fr/ ). Are they a useful start? What should be the next step?
I like the idea, especially the amendments you can visualize almost like a commit tree. They should add something to search like the oldest laws which often are deprecated and useless, in order to help get rid of them.
Last but not least, it is to maintain this website, last updates seem to be from 2022. But I can't manage to imagine if it's a lot of work or not.
You can withdraw consent later, but I don't see how that would affect data processed before the withdrawal (except that storage is processing and the data would have to be deleted). I don't imagine a reputable employer would have any other use for the data, so the withdrawal of your consent might not bother them much. If your application were successful and you took the job, I expect that would establish contract, rather than consent, as a legal basis for them to process your data.
In general, I'm not sure a company processing my data on the basis of consent would stop all processing of my data just because I withdraw my consent. Some processing of some of my data might have a different legal basis. Judging by some websites' privacy options, there's a distinction between consent (opt-in), legitimate interest (opt-out) and other legal bases (maybe neither). I'm confused about website forms that have separate reject and object options for each category of data processing and a reject-all button that closes the form. Does clicking "reject all" mean I have or haven't objected?
Thanks. Appreciate the thought trail. For an employer, if they delete the data later (if I don't get the job) then I'm ok with that since I'm expecting it to be accessed and used by humans.
Interesting about the website forms that have separate options for each category, I'd always believed this was to wear me down so I click "agree" once instead of changing 98 separate sliders to no.
But if laws can override contracts (which presumably they can), then contracts can appear to establish permissions/restrictions that are illegal. At least one contract I've signed includes something about the rest being enforceable if any part of it isn't enforceable. Perhaps that helps to contain actual mistakes, but I assume employers use it to persuade employees that they're bound by illegal non-compete clauses, for example.
> At least one contract I've signed includes something about the rest being enforceable if any part of it isn't enforceable.
Which is funny, because if it worked like that - that any unenforceable demand in it made the whole thing invalid - then presumably the clause asserting the opposite would also be invalid.
This is my understanding, too. Sorry if that wasn't clear in my earlier comment.
However, I also believe that unenforceable parts of a contract have no effect, except in the minds of the parties to that contract. My suspicion is that contracts are sometimes drafted with this in mind.
> But electronic 'equivalents' of neural nets is one area where analog might make sense.
That's an interesting idea, but could the weights be transferred to different hardware and still work? If not, that would be a significant limitation, even if it were preferable in some cases.
GluconScript looks cool, but this sounds too good to be true:
> as a bonus, since Rust takes care of all the ownership
> and lifetimes, I don't need a garbage collector.
I can imagine GluconScript's memory handling comes at a cost, even if the tradeoff of using a borrow checker is well worth it. Was that your experience?
Relatedly, since you commented there has been submission about garbage collectors in Rust ("Garbage Collection Without Unsafe Code"):
GluonScript really doesn't need a garbage collector, because at the end of the day when a script is executing, it is just safe Rust code evaluating expressions. So it's just a Rust program running really, with its automatic static memory management guarantees.
As far as I researched, only closures could generate dangling references and therefore need memory cleanup, but only if I allowed closures to access their environment (variables and functions) by reference / mutable reference.
To avoid this and simplify both my code as well as the mental model for the users of GluonScript, as of now, closures capture their environment by cloning it immutably. There's an increased memory usage with all the copying of the environment but there are never references to something that isn't being used anymore and therefore no need for a GC. At the end of the day all values captured by closures are owned Rust values that are dropped by Rust when no longer in scope.
So this can lead to high memory usage in hot loops but it can't lead to memory leaks.
It would be good. There have been some attempts at source code style revision management for statutes (such as https://www.lafabriquedelaloi.fr/ ). Are they a useful start? What should be the next step?