Hacker News Reader

>Many, if not most of these things are problems with the environment, not things programmers should think about or try to solve. In fact, most of them should explicitly not be thought about. All that that will do is lead to defensive programming - What if X happens? What if Y? The answer to most of them is simple - Crash.

When it comes to time, a crash is not the most likely outcome of not thinking about what could happen. More likely your code will stall or do the wrong thing.

Think about polling, pinging other systems or rate limiting. At the end of daylight savings time your code could easily stall for an hour or DDOS another system because rate limiting fails.

There are situations in which it is not acceptable to make a "loud crash", e.g., while a plane is flying.

There was a quote by a nasa engineer that an incorrect action is better than no action at all, but I cant find it at the moment.

I'm pretty sure that if a flight computer detects an inconsistency, it will immediately reboot, and not try to limp along in a bad state. Either the reboot is fast enough to recover quickly enough, or the redundant systems will take over.

No.

Yesterday my friends Mac crashed hard while they were working on a foolishly unsaved one-and-a-half page document in LibreOffice.

At the next start LibreOffice gives a big warning of "Oh shit things are really wrong, should I fix them for you? [Continue | Cancel]" .

Thank you LibreOffice team for making it so that within the time of a phone call to me plus the time it took to press "Continue" they were able to recover the their document and continue working.

This "attempt to rectify" the problem, could only have made things better not worse, so that's reasonable to implement.

I am not saying that every problem needs a solution like this. But blanket statements like "crash whenever there is a problem with your environment", while certainly the correct way to do it in some cases, leads to software that's really shitty use if that's all the software does.

Because while

> Almost all of these are the wrong numbers.

is correct from a programmers point of view, we aren't talking about the numbers a user put in, but rather numbers that the user has no control about.

And not many things are more annoying than computers doing unexpected things for reasons that are incomprehensible to you.

I don't think parent comment meant ditching swap files in text editors or reboot on GPS errors in plane's autopilot. Just sort out upfront where the value is (user data, safety and reliability, rendering fast, etc…) and set requirements appropriately.

There is no reason to handle leap seconds in a flappy bird game, or fork your database server to implement "proper" time handling with historically correct time zones and all the appropriate conversions between them, if you are writing a Twitter client.

>At the next start LibreOffice gives a big warning of "Oh shit things are really wrong, should I fix them for you? [Continue | Cancel]" .

> Thank you LibreOffice team for making it so that within the time of a phone call to me plus the time it took to press "Continue" they were able to recover the their document and continue working.

Uh, that's exactly what the OP was advocating, if I understand correctly. On a consistency check failure (i.e. an assert), crash immediately [1]. If the application correctly handle transactional state changes, it will be able to recover on startup from the replay log, as all changes are immediately persisted on the log.

This approach is known as "Crash Only Software", and it is pretty much the only approach for writing robust applications.

[1] Syncing the replay log to stable storage can be a good thing though.

Yes, and I'm consistently disappointed that HN no longer gets this - It's becoming an echo chamber of those who can't and won't, rather than those who architect and learn. Timekeeping considerations are rarely-to-never the responsibility of an application programmer, and the scenarios presented - Leap seconds, etc - Are either meaningless (Who cares if your delta-t value is off by a second over a three month report?) or incredibly meaningful to the point you explicitly define them in the spec (High-freqeuncy trading systems should use good linearization mechanisms, not just rely on 'timestamp' - The programmers who are working on these problems have well documented that these are hard problems that throwing more time specificity bits doesn't solve).

High level talks about low-level concerns are rarely helpful. This overview of detailed problems without links or even understanding of the relevant literature (It doesn't even mention the scenario that time runs backwards, which is way more common and terrible than pretty much anything on the list). This was a bad post, and it's bad training - Bringing up superficial questions without giving places to check answers for sanity. Many people will likely think about these issues halfheartedly, form half-baked answers, and propagate mistakes. Good learning not only asks questions, but asks follow ups and helps reach complete solutions.

Yes. To further play devil's advocate; a lot of times it's better to just write time handling in a naive manner. Even if you know it will fail under certain circumstances, the program might not need to always be correct to be successful. I HATE writing stuff like this, but sometimes the ROI is just not there.

Yeah, same thing I was thinking. Being exact in time can drive you crazy. Don't run yourself in the ground.