Final by default?

[Walter Bright]

I'd like to address, in general, the issue of, what I term, "performance by 
default" which is part of the argument for final by default.

C, C++, and D are billed as languages for writing high performance apps. And 
this is true. What is not true, or at least has not been true in my experience, 
is that an application is high performance merely because it is written in C, 
C++ or D.

Let me emphasize, code is not fast just because it is written using a high 
performance language.

High performance code does not happen by accident, it has to be intentionally 
written that way. Furthermore, I can pretty much guarantee you that if an 
application has never been profiled, its speed can be doubled by using a 
profiler. And if you really, really want high performance code, you're going to 
have to spend time looking at the assembler dumps of the code and tweaking the 
source code to get things right.

High performance code is not going to emanate from those programmers who are not 
skilled in the art, it is not going to happen by accident, it is not going to 
happen by following best practices, it is not going to happen just because 
you're writing in C/C++/D.

D certainly provides what is necessary to write code that blows away 
conventional C or C++ code.

It reminds me of when I worked in a machine shop in college. I'd toil for hours 
cutting parts, and the parts were not round, the holes were off center, heck, 
the surfaces weren't that smooth. There was an older machinist there who'd take 
pity on me. He'd look at what I was doing, cluck cluck, he'd touch the bit with 
a grinder, he'd tweak the feed speed, he'd make arcane adjustments to the 
machine tool, and out would come perfect parts. I am an awe to this day of his 
skill - I still don't know how he did it. The point is, he and I were using the 
same tools. He knew how to make them sing, I didn't.

I still cannot drill a goddam hole and get it where I measured it should be.