[article] Language Design Deal Breakers

[Peter Alexander]

On Sunday, 26 May 2013 at 12:59:27 UTC, Walter Bright wrote:
> On 5/26/2013 4:03 AM, Paulo Pinto wrote:
>> Am 26.05.2013 09:27, schrieb Walter Bright:
>>> That would imply that statically removing null pointers would 
>>> halve
>>> total debugging time. Is there any evidence of that?
>>>
>>
>> Well at least for Android, yes there is a proof.
>>
>> http://blog.bugsense.com/post/49924755479/bigdata-in-motion-building-a-real-time-android
>
> You're assuming that "all program bugs exhibit themselves as a 
> crash". This is quite false.

True, clearly the claim of "halve" is false, but I think we can 
all agree from this data that null pointers are a frequent cause 
of crashes, for some value of "frequent".

Given that your primary area of work is in compilers, you will 
have a skewed perspective of what types of bugs are common. 
Compilers typically allocate a lot, to build up the AST, perform 
semantic analysis, emit code, then shutdown. There isn't much 
opportunity for null pointer dereferences in this kind of program 
because pointers are rarely set to null after they have been 
initialised.

In contrast, interactive applications such as games and GUI apps 
have many opportunities for null pointers. For example, GUI's 
typically have a pointer/reference to the widget that currently 
has focus, and may be null if no widget has focus. Everything 
that uses that reference has to check for null, and it's easy to 
forget. It's also difficult to unit test GUIs. A language that 
statically enforces the programmer to check for null would help 
here.