If you feed data to a LLM then there will always be a prompt injection. What you described is limiting the damage that the prompt injection can do, but also its usefulness.
Density is not the correct measure here because empty land decreases density but doesn't need to be covered. What matters is how much the population is clustered.
I graduated from a not so incredible university and we had multiple such rooms. Teaching assistants and some tutors helped supervising the exams and it wasn't easy to cheat without getting caught.
It has a Rust-like syntax, enums, matching, traits, etc etc. Yes, it also loses a lot of special characteristics of Rust, but it has to be different somewhere. Moreover a lot of people like Rust as a high level language, i.e. ignoring the lower level capabilities and lifetimes, and this seems to be a direct response to that feeling.
If you are into constructive logic then this will only work for proving negative statements (where indeed the definition is the same as what a proof by contradiction would give you). For positive statements you won't get back a direct proof term of your initial statement, but rather a proof of a double negation of it.
My understanding is that the "logical bits" view breaks down for unions, because the nth logical bit could be at different offsets depending on the union variant that's considered active.
Everyone talking about malware in dev dependencies as if dependabot only raises issues about that, but it does not. It raises warnings about all sort of "vulnerabilities" irrespective of the threat model.
Even worse, it incentivizes randomly updating dependencies, which is what actually allows supply chain attacks.
Do you need a blockchain for that though? There are cryptography schemes to share a secret (e.g. the recovery keys) between multiple parties, requiring at least N of them to get together to recover the original value of the secret.
> A bad abstraction would at least have had one fire in one place
That's true only for "good" abstractions. Bad abstractions will often require you to change code in all the places using it, requiring you to understand how all of them work and what are their requirements, _all at the same time_.
And you did not notice how many things require Google Apps/Play Integrity? Heck, most people don't even know how to install apps without the Play Store.
> I've been thinking about this in art. Is it the end result that matters, or the process of creating it?
What is the "end result" you're talking about here?
Programs are complex beasts, you cannot just quickly look at them and get an idea of what's they are actually doing. You might look at the behavior of the program in some limited circumstances, but that will make you blind to all the other situations where bugs will likely hide! In the end a code review is looking at what the "end result" is, and it requires quite a lot of effort!
So without knowing what the end result is, how can you justify the effort for such code review? And that's where the process comes in, as an indicator of what to expect.