5 ms·

> All software is buggy on real hardware. definitely not "buggy" is a logical property of the program as expressed, not a physical property of the program as

> All software is buggy on real hardware. definitely not "buggy" is a logical property of the program as expressed, not a physical property of the program as executed a solar ray flipping a memory bit on the hardware executing an otherwise correct program does not make that program buggy > There's an implicit "hope not to hit the ultra rare bad luck" on each line of code. there definitely is not, at least in the context of the program as expressed such a case of "bad luck" would violate the assumptions of the language model, and/or execution model, and/or hardware model, and/or etc., of the running program, in a way that would be likely undetectable and definitely un-fixable it would be an invariant violation of the hardware/os/language model -- but a bug is a logic error it is so important that programmers understand this distinction fn f1(x int) -> int { return x } fn f2(x int) -> int { if x==2 { panic } else { return x } } fn f3(x int) -> int { if rand() < 1e-10 { panic } else { return x } } f1 is correct, f2 is buggy, and f3 is buggy -- no matter if 1e-10 is 1e-10 or 1e-20 or 1e-30

Dylan16807 3y ago
> such a case of "bad luck" would violate the assumptions of the language model, and/or execution model, and/or hardware model, and/or etc., of the running program, in a way that would be likely undetectable and definitely un-fixable Yes, assumptions. Everyone can only assume the bad luck won't happen despite it being a nonzero chance. Even if you want to play in the land of pure math, where software does as it's told, every mainstream compiler has bugs. Sometimes assuming things that aren't strictly true is the best path forward. That's why my first post started with "You can and should assume sufficiently likely things. It's a waste of time to worry about probabilities with enough zeroes." > it is so important that programmers understand this distinction Why is it important? Though I do understand the difference, while at the same time describing circumstances where it doesn't matter. And the breadth of those circumstances depends on the probability.
- preseinger 3y ago
  you would therefore not object to a PR which added if randf32() < P { panic } to the beginning of every function in your code base, if P was sufficiently small?
  - Dylan16807 3y ago
    For f32, there is no sufficiently small P. If it was a random 1/2^200 chance, I would not object to it for the random chance. But it would have to actually improve the program execution in a significant way before I accept it. I wouldn't accept "if rand() < P { NOP }" being stuck into every function without a tangible benefit either, despite how safe it is. I didn't notice https://news.ycombinator.com/item?id=36330673 https://news.ycombinator.com/item?id=36330673 until just now but the first half sounds like you're agreeing with me. You can't remove the risk of solar rays, so you just have to live with it. 0% risk is an unreasonable standard. Certain things have to be outside your execution model, even though they're technically possible. Small small chances of logic errors don't have to be outside your execution model, obviously. But if they're a lot rarer than the errors you have to ignore, then you get no benefit from including them in your execution model. > if you want to make the assumption that secure_rand_u128 will never return 0, then you have to justify that assumption in the context of your specific use case -- it absolutely cannot be assumed in the general case I can agree with this... but my use case is 99.9% of all computing in the year 2023. Normal computers are not reliable enough to measure the difference in error rate of an occasional 1/2^128 chance.

Dylan16807 3y ago

> such a case of "bad luck" would violate the assumptions of the language model, and/or execution model, and/or hardware model, and/or etc., of the running program, in a way that would be likely undetectable and definitely un-fixable Yes, assumptions. Everyone can only assume the bad luck won't happen despite it being a nonzero chance. Even if you want to play in the land of pure math, where software does as it's told, every mainstream compiler has bugs. Sometimes assuming things that aren't strictly true is the best path forward. That's why my first post started with "You can and should assume sufficiently likely things. It's a waste of time to worry about probabilities with enough zeroes." > it is so important that programmers understand this distinction Why is it important? Though I do understand the difference, while at the same time describing circumstances where it doesn't matter. And the breadth of those circumstances depends on the probability.

preseinger 3y ago
you would therefore not object to a PR which added if randf32() < P { panic } to the beginning of every function in your code base, if P was sufficiently small?
- Dylan16807 3y ago
  For f32, there is no sufficiently small P. If it was a random 1/2^200 chance, I would not object to it for the random chance. But it would have to actually improve the program execution in a significant way before I accept it. I wouldn't accept "if rand() < P { NOP }" being stuck into every function without a tangible benefit either, despite how safe it is. I didn't notice https://news.ycombinator.com/item?id=36330673 https://news.ycombinator.com/item?id=36330673 until just now but the first half sounds like you're agreeing with me. You can't remove the risk of solar rays, so you just have to live with it. 0% risk is an unreasonable standard. Certain things have to be outside your execution model, even though they're technically possible. Small small chances of logic errors don't have to be outside your execution model, obviously. But if they're a lot rarer than the errors you have to ignore, then you get no benefit from including them in your execution model. > if you want to make the assumption that secure_rand_u128 will never return 0, then you have to justify that assumption in the context of your specific use case -- it absolutely cannot be assumed in the general case I can agree with this... but my use case is 99.9% of all computing in the year 2023. Normal computers are not reliable enough to measure the difference in error rate of an occasional 1/2^128 chance.