D benchmark code review

[Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com>]

On Sunday, 15 December 2013 at 04:50:20 UTC, Walter Bright wrote:
> Back when there was only one D compiler, people said they 
> wouldn't use it because there was only one. Now people won't 
> use it because there are 3.

Not quite, I think people were unhappy because it wasn't fully 
open source back then. I am currently (possibly being wrong) 
perceiving the current D-compiler community to be fragmented. In 
the same sense that BSD is fragmented. Linux isn't fragmented, 
and stronger because of it, there is one authoritative kernel and 
some minor spin-offs. Compilers are usually never 100% compatible 
so having one dominating compiler that "everybody" use is 
beneficial.

> Essentially, if you want to find a reason not to use D, you'll 
> find one. But if you want to use D, there are lots of reasons 
> to.

Actually, I wouldn't track dlang.org for years if I wasn't 
looking for a reason to use it. I do try it from time to time, 
but it never fits the things I want it to do, because D like Go 
is claiming to be a better C, but is not giving me the level of 
control I want. And I really do want a better C/C++, if for no 
other reason than that header files sucks.

In general I think programming languages get traction, not 
because they are good languages, but because they are best-fit 
for a particular application domain. So I think a language like D 
would benefit from being the best "modern" solution in one 
particular area, like embedded programming.

When creating a programming environment it is important to 
realize that human brains are bad at logic, dog slow, it cannot 
do it. It does approximations to logic, the approximations are 
worse when you get noise into the system. When you are 
programming the brain is more or less saturated constantly and 
stutters because information is relayed in and out of "working 
memory" (which is a fuzzy process and a source of errors). 
However, the brain has very powerful "hardwired" spatial/visual 
subsystems with spatial mapping and classification that work very 
well if the visual patterns are distinct and tailored to the kind 
of "visual fields" that you see in landscapes/faces etc which it 
has be evolved to deal with. You want to utilize that to it's 
fullest potential. In c++ some symbols are very easy to detect, 
like "::" and "[", you don't have to think to classify spatial 
areas where those visual constructs occur as regions of 
namespacedness and arrayish, because they are not used for other 
things. So you can train the subconscious cognitive pattern to 
correctly classify them without doing any resolution. There is a 
reason for why road signs differ in shape, colours and have very 
distinct silhouettes as symbols, it supports recognition without 
disturbing the conscious parts of the brain that deals with 
avoiding danger while driving. The moment you have to think about 
what a sign means you are much more likely to make errors, which 
while driving can be fatal. When programming it isn't fatal, but 
you get more bugs, or become slower.

IIRC Manu thinks that it is better to have "{" on a separate 
line. Is he correct? Yes, in terms of pattern recognition he is. 
Visual marks that are surrounded by open space is more likely to 
be correctly grouped, detected and visually classified. If you 
use the Egyptian style you basically don't rely on the braces as 
symbols to the same extent, you rely on line-detection of 
indentation. So you need larger indentation in order to establish 
horisontal lines. Why is that? Because the visual subsystems of 
the brain is hardwired to detect contours of objects/regions. If 
the indentation is too small the visual subsystems will fail to 
detect breaks in the vertical lines and will group nested blocks 
as one block, until the conscious parts of the brain says 
"no-no-wait" and has to resolve the error/ambiguity.

When programming in assembly programmers tend to do sketches on 
paper, why is that? Because that makes it possible for them to 
utilize the visual cognitive capabilities of the brain in 
addition to the dog-slow-quasi-logical-reasoning of the human 
brain. That creates a mental map of the program which assembly 
doesn