(non)nullable types

[Jarrett Billingsley]

On Fri, Feb 13, 2009 at 5:52 PM, Daniel Keep
<daniel.keep.lists at gmail.com> wrote:
> Both of these syntaxes are solving a problem that doesn't exist.  This
> is why we have null dereference exceptions: accessing a null pointer is
> an error.  All this is doing is moving the onus for the check from the
> hardware to the programmer.
>
> Leave magic out of the language and let the hardware do it's job.  If
> you have a nullable type, it's because you WANT it to be nullable, and
> you shouldn't have to stand on one leg and jump through a burning hoop
> every time you want to look at the damn thing.

Having only nullable references with no non-null counterpart is like a
builder building houses with holes in the walls, whether the people
who live in them want them or not, so that small animals can get in.
Then the residents are forced to check that there are no small animals
in their house all the time rather than just _not building the house
with holes in the wall to begin with._

The hardware only has a job _to do_ because for decades languages have
not been smart enough to prevent invalid pointers to begin with.  You
could even argue that letting the hardware catch null pointers is an
abuse of what the virtual memory hardware is meant for - keeping
processes from messing with each others' data, not ensuring program
correctness.  Ensuring program correctness is the compiler's job.