an impossible thing for developers
We tend to assume that every question has an answer, which, for example, is not true when we want to know what the current time is. Developers should increase awareness of unexpected failure modes, advertise the possibility of failure, and use timeouts to recover from waiting for a response that will never come.
Henney argued that there are things that are impossible, not “really difficult” or not feasible in time or budget, but actually impossible according to our understanding of how the universe works:
I found this idea of physical and mathematical limits interesting because it makes us think about the limits 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 ask for the current date and time from a frame, we assume that we will receive a response, and the response is a value that represents the current date and time. Our normal concern is the accuracy of the response or, if that request is frequent, the cost of the call, Henney said. What we don’t tend to consider is that there may not be an answer to this question available:
The current date and time aren’t some sort of universal truth that code can pull out of nowhere. Time is a service, not a global variable. Whether it comes from the operating system or the network, this call can – and fails -.
Concretely, this means that we need to increase our awareness of unexpected failure modes, distinguishing between behavior that is testable and under our control and code that has external dependencies that are not under our control, as explained Henney:
If we write code that has these properties, we must ensure that the possibility of failure is clearly announced to callers.
There are many far less esoteric situations where we encounter this situation of waiting for an answer that will never come, Henney mentioned. That’s why timeouts exist and are a critical part of every layer of the software stack, from network management to automated application testing.
InfoQ interviewed Kevlin Henney about unanswered questions.
InfoQ: What can happen when there are situations where there is no answer?
Kevin Henney: A request for time that does not necessarily have time as an answer arises from assumptions about the problem domain rather than failures in the solution domain. Consider that 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 answers regarding the time of day. For example, Tromsø in the far north of Norway does not have sunrise or sunset times from late November to mid-January when there is permanent night, or from mid-May at the end of July, when there is permanent daylight. Many developers ignore this, leading to either runtime errors or incorrectly displaying 00:00 as the result.
Another compelling example of a question being unanswered relates to computability rather than resources or domain assumptions. In the previous example, no response could be returned based on the query terms of reference. What happens 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 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 attempted to do this, it would never complete. There is no answer to this question, and more importantly, we can’t just rephrase the question to account for some kind of error feedback.
Likewise, there is no way to write a general algorithm that will determine whether an arbitrary piece of code will terminate or not. This is the stopping problem. In 1936, Alan Turing proved that such an algorithm did not exist. If such an algorithm existed, we would expect to feed it a piece of code and always receive a “yes” or “no” response. There is, however, a third possibility, which is that the code for determining whether another piece of code will terminate itself never terminates. We are never given an answer to this question.