Technology is continuing to come up with things that are impossible to make money at. Scarcity is slowly being abolished. It seems one of the core aspects of the singularity is the general dismantling of the money-based economy we've become so used to.

First there was the internet, now there's this.

In the aggregation of all the code I write, some of it HAS to be correct and some of it, not so much so. Actually it's more of a spectrum from super mission critical to meh, who cares. Given the degree to which computers are working their way into everything we do, I'm sure that there is code out there now, the correctness of which has life or death consequences.

That's why I consider strongly typed compiled languages to be important. I want to be able to guarantee correctness at compile time, as much as is possible, for these types of applications. Yes, of course there's unit testing, or coverage testing, the idea being to cover as much of the use cases as possible, and there are strong arguments for testing before you write anything, but I consider that to be a back up to compiler verification. Unit testing can't possibly cover every scenario.

Suppose you, as a programmer, were held liable for what your software did. Could you possibly find a way to write any more code? Would your calling in life be at an end? If tomorrow, congress passed legislation making programmers liable, I believe we would find a way and that way would be through strong compilers, unit tests, and digital signatures, all of which we would be prepared to take to court.

Another thought about compiler null checking: A method signature is a contract between the method provider and the method consumer, but it doesn't say anything about nulls. If the method provider and method consumer have no other means of communication, they both have to check for nulls. The consumer should make sure the method arguments are not null before calling the method and the provider has to check for nulls before using them since neither of them can trust the other. Of course the provider can just say that a NullPointerException is going to be thrown should the consumer be so stupid as to pass a null, and that's what is often done. But that is a run-time bug just waiting to hide in the bushes, avoiding unit tests and the QA tests and the UA tests, and spring out years down the road, when the software is in production and the development staff is long gone. No, I think what's really needed is for the Java language to add the NOTNULL qualifier to method arguments and enforce it. The compiler can know whether an argument could be null.