We tend to assume that every question has an answer, which for instance isn’t true when we want to find out what the current time is. Developers should increase awareness of unexpected failure modes, advertise the possibility of failure, and use time-outs to recover from waiting for an answer that will never come.
Kevlin Henney gave a keynote about Six Impossible Things at QCon London 2022 and will be presenting at QCon Plus May 10-20, 2022.
Henney argued that there are some things that are impossible, not "really hard" or not feasible in the time or budget, but actually impossible according to our understanding of how the universe works:
I have found this idea of physical and mathematical limits to be interesting because it makes us think about the boundaries of our work. It offers a more reasonable alternative to the narrative that anything is possible with enough effort and innovation. The universe says otherwise.
If we request the current date and time from a framework, we assume we will receive an answer and that the answer is a value that represents the current date and time. Our normal concern is over the accuracy of the answer or, if this request is frequent, the cost of the call, Henney said. What we don’t tend to factor in is that there may not be an answer to that question available:
Current date and time is not somehow a universal truth that code can pluck from thin air. Time is a service, not a global variable. Whether it comes from the operating system or the network, that call can — and does — fail.
What this means in practical terms is that we should increase our awareness of unexpected failure modes, distinguishing between behaviour that is testable and under our control and code that has external dependencies not under our control, as Henney explained:
If we are writing code that has these properties, we should make sure that the possibility of failure is clearly advertised to callers.
There are many situations that are far less esoteric where we encounter this situation of waiting for an answer that will never come, Henney mentioned. This is why timeouts exist and are an essential part of every layer of software stack, from network handling to automated application testing.
InfoQ interviewed Kevlin Henney about questions without answers.
InfoQ: What can happen when there are situations when there isn’t an answer?
Kevlin Henney: A request for time that does not necessarily have time as an answer comes from assumptions about the problem domain rather than failures in the solution domain. Consider, many sites and newspapers publish sunrise and sunset times for various locations on a given day. The questions "What time is sunrise?" and "What time is sunset?" do not always have meaningful time-of-day answers. For example, Tromsø, in the far north of Norway, does not have any sunrise or sunset times from late November to mid-January, when there is permanent night, or from mid-May to late July, when there is permanent daylight. Many developers overlook this, leading either to runtime errors or to falsely displaying 00:00 as the result.
Another compelling example of there being no answer to a question concerns computability rather than resources or domain assumptions. In the previous example, no answer could be returned based on the terms of reference of the query. What if no return of any kind is possible?
InfoQ: Are there also questions that cannot be answered?
Henney: We have a special name for procedures that terminate: they are called algorithms. By definition, there is no such thing as an algorithm that does not terminate. There is no algorithm to find the last digit of pi, for example. If you were to run code that tried to do this, it would never terminate. There is no answer to that question and, importantly, we cannot simply rephrase the question to accommodate some kind of error return.
Similarly, there is no way to write a general algorithm that will determine whether or not an arbitrary piece of code will terminate. This is the Halting Problem. In 1936 Alan Turing proved no such algorithm exists. If such an algorithm existed, we would expect to feed it a piece of code and always receive an answer, either "yes" or "no". There is, however, a third possibility, which is that the code to determine whether another piece of code will terminate itself never terminates. We are never given an answer to that question.
