Which D features to emphasize for academic review article

Era Scarecrow rtcvb32 at yahoo.com
Sat Aug 11 17:28:29 PDT 2012


On Saturday, 11 August 2012 at 23:49:18 UTC, Chad J wrote:
> On 08/10/2012 06:01 PM, Walter Bright wrote:
>> It catches only a subset of these at compile time. I can craft 
>> any number of ways of getting it to miss diagnosing it. 
>> Consider this one:
>>
>> float z;
>> if (condition1)
>> z = 5;
>> ... lotsa code ...
>> if (condition2)
>> z++;
>>
>> To diagnose this correctly, the static analyzer would have to 
>> determine that condition1 produces the same result as 
>> condition2, or not. This is impossible to prove. So the static 
>> analyzer either gives up and lets it pass, or issues an 
>> incorrect diagnostic. So our intrepid programmer is forced to 
>> write:
>>
>> float z = 0;
>> if (condition1)
>> z = 5;
>> ... lotsa code ...
>> if (condition2)
>> z++;
>>
>> Now, as it may turn out, for your algorithm the value "0" is 
>> an out-of-range, incorrect value. Not a problem as it is a 
>> dead assignment, right?
>>
>> But then the maintenance programmer comes along and changes 
>> condition1 so it is not always the same as condition2, and now 
>> the z++ sees the invalid "0" value sometimes, and a silent bug 
>> is introduced.
>>
>> This bug will not remain undetected with the default NaN 
>> initialization.

  Let's keep in mind everyone of these truths:

1) Programmers are lazy; If you can get away with not 
initializing something then you'll avoid it. In C I've failed to 
initialized variables many times until a bug crops up and it's 
difficult to find sometimes, where a NaN or equiv would have 
quickly cropped them out before running with any real data.

2) There are a lot of inexperienced programmers. I worked for a 
company for a short period of time that did minimal training on a 
language like Java, where I ended up being seen as an utter 
genius (compared to even the teachers).

3) Bugs in a large environment and/or scenarios are far more 
difficult if not impossible to debug. I've made a program that 
handles merging of various dialogs (using double linked-like 
lists); I can debug them if they are 100 or less to work with, 
but after 100 (and often it's tens of thousands) it can become 
such a pain based on it's indirection and how the original 
structure was built that I refuse based on difficulty vs end 
results (Plus sanity).

  We also need to sometimes laugh at our mistakes, and learn from 
others. I'll recommend everyone read from rinkworks a bit if you 
have the time and refresh yourselves.

  http://www.rinkworks.com/stupid/cs_programming.shtml


More information about the Digitalmars-d mailing list