Null references redux

[Jeremie Pelletier]

language_fan wrote:
> Wed, 30 Sep 2009 12:05:29 -0400, Jeremie Pelletier thusly wrote:
> 
>> Don wrote:
>>> Greater risks come from using more complicated algorithms. Brute-force
>>> algorithms are always the easiest ones to get right <g>.
>> I'm not sure I agree with that. Those algorithms are pretty isolated and
>> really easy to write unittests for so I don't see where the risk is when
>> writing more complex algorithms, it's obviously harder, but not riskier.
> 
> Do you recommend writing larger algorithms like a hard real-time 
> distributed (let's say e.g. for 100+ processes/nodes) garbage collector 
> or even larger stuff like btrfs or ntfs file system drivers in assembly? 
> Don't you care about portability? Of course it would be nice to provide 
> optimal solution for each platform and for each use case, but 
> unfortunately the TCO thinking managers do not often agree.

Why does everyone associate complexity with assembly? You can write a 
more complex algorithm in the same language as the original one and get 
quite a good performance boost (ie binary search vs walking an array). 
Assembly is only useful to optimize when you found the optimal algorithm 
and want to lower its overhead a step further.

I don't recommend any language anyways, the base algorithm is often 
independent of its implementation language, be it implemented in C#, D 
or assembly its gonna do the same thing at different performance levels.

For example a simple binary search is already faster in D than in say 
JavaScript, but its even faster in assembly than in D, that doesn't make 
your entire program harder to code, nor does it change the logic.