In the graphic from the example we would keep track like this:
low: - high -
low: 11 high: -
low: 23 high: -
low: 23 high: 26
Error: now we see item 13, but that is not inside our span!
How can we detect PHBs if they exist? If they existed in large numbers, would we notice them? The paper says that you would notice a PHB if it went through you, since you would likely die. We are not noticing people dying by mysterious gunshot-like wounds without guns in any large amounts, so there can not be that many PHBs around.
The paper is (weak) evidence against a large amount of PHBs. The paper is also slightly funny.
yt-dlp -f "bv[height<=720]" <url>
(where <url> is your URL or video ID)That will download up to 720p quality.
Someone malicious doesn't care about laws anyway. If they get caught today, couldn't they could just deny that they were there? I don't understand what would change in that case.
Why is that? I've never seen a good explanation of this point of view.
This all feels like just syntactic sugar to me. Sure you might not have null, you might have an empty object or any other variation. At the end of the day, if a value was expected to be available but is not available (for whatever reason), reliable code is going to have to deal with that absence. No matter how it is expressed.
If you have a non-null returning function that you need to change so it can return null, then your typechecker will tell you all the places where you now need to handle the new null return.
It doesn't need to be a very large codebase before this becomes a very useful tool to help when refactoring.
Getting rid of check does make for a better game at beginner levels.
It's both easier to teach and leads to exciting finishes ss noobs hang their king.