Our programming languages professor, Robert Harper, recently talked about this concept in class. Although he argued that there was "no such thing" as a null pointer, what he actually meant to say was either there shouldn't be such a thing, or that a properly designed language would not have such a notion.
Consider SML (which, incidentally, he helped design). There are of course basic types, ints and bools etc, but it also has the notion of an "option" datatype. A foo option can either be NONE, or SOME of foo. For example, if you are doing some calculation that returns an int but may somehow fail to calculate its result, it will return an int option, with either SOME(result) if there was success, or NONE if it failed. Due to SML's strong type system, the function using that result would have to do case analysis on the result -- you can't use an int option as if it were an int; you need to pattern match and grab the int out of the SOME case and otherwise handle the NONE case.
Java (and C and...) doesn't do this properly. Take an ArrayList, for example. When you say "ArrayList foo", what you actually have is an ArrayList option, he argued, since you really either have SOME(an actual ArrayList) or NONE, representing the null pointer. Except Java has no notion of option types. There's no way to actually get an ArrayList -- you always have an ArrayList option. You have to check for NULL every time.
Thus his argument for why Java et al are badly designed, and how you can properly design a programming language without a need for a NULL pointer -- you use a different type altogether, upon which you can properly case analyze.
