Real-world use cases for map's None fill-in feature?

[Steven D'Aprano]

rurpy at yahoo.com wrote:

>>4. A terminating bug is preferred to a non-terminating bug.
> 
> 
> This is not self-evident to me.  Is this somehow
> related to the design philosophy of functional
> languages?  I was never aware of such a preference
> in conventional procedural languages (though I
> could easily be wrong).
> 
> It also seems directly counter to Python's "no errors
> should pass silently" dogma -- a non termination
> seems more noticable than silent erroneous results.

You are assuming that the function in question returns 
a result *quickly*, and that any delay  obvious to the 
user is clearly a problem ("damn program has hung...").

Consider a generic function which may take "a long 
time" to return a result. How long do you wait before 
you conclude it has hung? A minute? An hour? A day? A 
month? A year? If you have some knowledge of the 
expected running time you can make a good estimate 
("well, there are only a thousand records in the 
database, so even if it takes an entire minute to check 
each record, if it hasn't returned after 17 hours, it 
is probably hung"). But for arbitrary problems, you 
might not know enough about the function and data to 
make that estimate. Some calculations do have to run 
for days or weeks or months to get a correct result, 
and some are impossible to predict in advance.

So, in general, it is impossible to tell the difference 
between a non-terminating bug and a correct calculation 
that would have finished if you had just waited a 
little longer. (How much is a little longer?) Hence, in 
general, a terminating wrong answer is easier to test 
for than a non-terminating bug.


-- 
Steven.