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
