(non)nullable types

[Sebastian Biallas]

Christopher Wright wrote:
> Sebastian Biallas wrote:
>> Christopher Wright wrote:
>>> Oh, and I vote no. I think it's needless complexity. I code without 
>>> any special care for null objects, and I get a segfault or 
>>> NullReferenceException maybe once a week, probably less. I've always 
>>> been able to track down the bug very quickly.
>>
>> That misses the point completely. It's not about you (as the 
>> programmer) getting NPEs; it's about the user getting bug-free 
>> software in the first place.
>>
>> In most cases a segfault/NPE is easy to track down for the programmer, 
>> I guess nobody would object to this. But once the software is shipped, 
>> it's a very serious problem: It's a situation the programmer didn't 
>> thought about so you usually have a data loss.
> 
> Your language features should get rid of bugs that are easy to make and 
> difficult to track down. It's not worthwhile to alter your language to 
> remove easily found, easily fixed bugs.

Once your software is running, an easy to fix bug is just as bad as an 
hard to fix bug. It's a bug after all.

Of course, you can ask the question whether it's worthwhile to alter the 
language. Well, for D this is still possible, while other languages will 
have NPEs till the end of the world.

> Logic errors are difficult to find. Your language cannot help you 
> eliminate those (though contracts and unittests can help you find them). 

"We shouldn't try to avoid bugs of type A because we can't avoid bugs of 
type B" is a logical fallacy.

> If you do not test your software extensively, you will ship software 
> with logic errors. The testing required to find logic errors will also 
> find low-level errors like segfaults.

Uh.... sorry, but reality proves you wrong. I (and the rest of the 
world) get NPE in various kinds of extensively tested software.

And we can get rid of *all* these errors by a simple language change (A 
change that should have been done centuries ago). This is a case where 
you can automatically proof correctness of a specific detail of your 
software. A chance that shouldn't be ignored because, uh, it's an easy 
to fix bug (If your rocket to the moon explodes because of an easy to 
fix bug, well, I don't think that is helps you that it was at least an 
easy to fix bug).

Sebsatian