Null references redux

[Jeremie Pelletier]

language_fan wrote:
> Wed, 30 Sep 2009 17:05:18 -0400, Jeremie Pelletier thusly wrote:
> 
>> 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.
> 
> Well I meant that we can assume the algorithm choice is already optimal.
> 
> Porting the high level program to assembly tends to grow the line count 
> quite a bit. For instance I have experience converting Java code to 
> Scala, and C++ to Haskell. In both cases the LOC will decrease about 
> 50-90%. If you convert things like foreach, ranges, complex expressions, 
> lambdas, an scope() constructs to assembly, it will increase the line 
> count at least one order of magnitude. Reading the lower level code is 
> much harder. And you lose important safety nets like the type system.

Yeah but I don't rate my code based on the number of lines I write, but 
rather on how well it performs :)

I usually only go into assembly after profiling, or when I know from the 
start its gonna be faster, such as matrix multiplication.

If lines of code were more important than performance, you'd get entire 
OSes and all their programs written in javascript, and you'd wait 20 
minutes for your computer to boot.