If I understand the argument correctly, it goes like this:
1/ A null pointer is a known address that doesn't actually point to an object of the expected type. It points to something else, but should never be dereferenced.
2/ dereferencing such a pointer is not only wrong, but it would lead to results that are not predictable from examining the original source code.
3/ therefore, every attempt to dereference a pointer must be preceded by a test to see if the pointer is "NULL", and to raise an exception if it is
4/ (I'm guessing here, this wasn't explicit in the talk but is the only way that the rest makes sense) Performing that test was too expensive on hardware at the time, so they didn't perform the test, so programs behaved in hard-to-understand ways which had a substantial cost either in debugging time or dealing with incorrect or harmful results.
If I am right, then:
A/ while it may have been a mistake then, it isn't relevant any more as any hardware with an MMU (which I think is everything these days) can easily check every dereference for 'NULL' and raise an exception, and
B/ The "billion dollars" is almost certainly an extreme over-estimate. The real problem is programmers writing bad code. Some other technique than NULL (e.g. explicit sentinal objects) might have made some of the problems easier to detect earlier and so might have saved something, but I really don't think it is justifiable to place that much blame on the 'NULL' pointer. Some maybe, but not much.
So I see absolutely no problem in a modern language allowing a NULL pointer, though certainly supporting non-NULLable pointers is very appropriate. And every runtime should check for dereferences of NULL (preferrably in hardware) and raise and exception when it happens. But I'm sure they do.
Posted Mar 31, 2011 11:16 UTC (Thu) by paulj (subscriber, #341)
[Link]
Agree.
NULL pointers are a red-herring. If we're talking about C level languages, then a NULL pointer dereference is a *good* kind of mistake - it's a clear error and causes an immediate exception at runtime, as you say. Much, much more insidious in C-level-akin languages is stale pointers and code continuing to twiddle memory that no longer references the state it thinks it should. Give me an immediate segfault over bugs which only cause crashes later, in unrelated code, any day! Further, even in managed-runtimes and with non-nullable types, you *still* can have stale references that cause bugs (which can still be hard to debug, even if it manages to better protect state from being corrupted).
The problem is just so much more fundamental: The correct management of the lifetime of state, and the co-ordination of visibility of that state.
(Functional programmers would of course argue the problem is best solved by never sharing state, only ever copying and transforming it. Course, while that removes scope for many kinds of crash-causing bugs, it still can't remove higher-level, logical mistakes..).
RE: nullable pointers
Posted Mar 31, 2011 14:55 UTC (Thu) by deweerdt (subscriber, #18159)
[Link]
Yes, I think some people extrapolated the title and created this internet rumor that simply switching to non-nullable pointers would automagically resolve all sorts of problems.
RE: nullable pointers
Posted Mar 31, 2011 19:56 UTC (Thu) by HelloWorld (guest, #56129)
[Link]
I don't agree with your interpretation of Hoare's talk. In the beginning, he says that Algol, unlike other languages at the time, checked array subscripts at runtime, which he thought of as a good idea, even though it was slow. So clearly, efficiency wasn't his primary concern.
He explains later on why he added null, and what it boils down to is that he didn't know how to do better.
RE: nullable pointers
Posted Apr 1, 2011 3:58 UTC (Fri) by neilbrown (subscriber, #359)
[Link]
It is very possible that my interpretation of Hoare's talk is flawed. It was a very unsatisfying talk, and I got the impression that he wasn't really expecting to give it and so wasn't really prepared. He said something about expecting to be part of a panel of people all sharing their "greatest mistakes" and went to some effort to get people in the audience to contribute - to argue for or against - to make it a more substantial discussion. So it would almost certainly be unfair to assess Tony Hoare's really thoughts based on that talk.
For the moment however that is all we have, and to my mind it came across a lot like the proverbial dot-com-boom business plan which you might remember as:
1 - give stuff away for free
2 - ....
3 - profit.
In this case it is
1 - Invent the NULL pointer
2 - ...
3 - Cause a billion dollars of damage.
In both cases there is no clear link from the first step and the third step.
I can happily agree that Tony Hoare invented NULL, and I can happy agree that programmer errors that manifested as dereferencing a NULL pointer have had a large cost, but I cannot see how the one leads to the other.
It would seem equivalent to blame Marie Currie for the current serious radiation problems in Japan. She coined the word "radioactivity" and radioactivity is causing serious problems and endangering lives. But it is hardly her fault.