D const design rationale

[Bill Baxter]

Walter Bright wrote:
> Sean Kelly wrote:
>> Walter Bright wrote:
>>> Sean Kelly wrote:
>>>> Matter of opinion, I suppose.  The C++ design was immediately clear 
>>>> to me, though it obviously wasn't for others.  I grant that the 
>>>> aliasing problem can be confusing, but I feel that it is a 
>>>> peripheral issue.
>>>
>>> I don't think it is a peripheral issue. It completely screws up 
>>> optimization, is useless for threading support, and has spawned 
>>> endless angst about why C++ code is slower than Fortran code.
>>
>> As a programmer, I consider the optimization problem to be a 
>> non-issue.    Optimization is just magic that happens to make my 
>> program run faster.
> 
> Optimization often makes the difference between a successful project and 
> a failure. C++ has failed to supplant FORTRAN, because although in every 
> respect but one C++ is better, that one - optimization of arrays - 
> matters a whole lot. It drives people using C++ to use inline assembler. 
> They spend a lot of time on the issue. Various proposals to fix it, like 
> 'noalias' and 'restrict', consume vast amounts of programmer time. And 
> time is money.

FORTRAN is also helped by having a fairly standardized ABI that can be 
called easily from lots of languages, which C++ lacks.  But C has that, 
and it has also failed to supplant FORTRAN for numeric code.  But I 
think Sean's right.  A lot of that is just that the language supports 
things like actual multi-dimensional arrays (by 'actual' I mean 
contiguous memory rather than pointers to pointers), and mathematical 
operations on them right out of the box.  Telling a numerics person that 
C/C++ will give them much better IO and GUI support, but take them a 
step back in terms of core numerics is like trying to sell a hunter a 
fancy new gun with a fantastic scope that will let you pinpoint a mouse 
at 500 yards but -- oh, I should mention it only shoots bb's.

On the other hand, I suspect there's lots of code that's written in 
FORTRAN supposedly for performance reasons that doesn't really need to 
be.  Just as there's lots of code written in C++ that would perform fine 
in a scripting language.  But people will still swear up and down that 
{whatever} is the only language fast enough.  A lot of numerics folks do 
realize this, however.  They just go from Fortran straight to Matlab, 
and skip the other compiled languages altogether.

I guess what I'd like to say in summary is that I'm skeptical about the 
claim that optimization "often" makes the difference between success and 
failure.  "occasionally" I could believe.  Ill-advised premature 
optimization has probably led to the demise of many more a project than 
actual optimization problems in the end product.  We'll all gladly take 
a free 20% speed improvement if the compiler can give it to us, but I 
don't believe there are that many projects that will fail simply for 
lack of that 20%.

--bb