dmd 1.041 and 2.026 releases

[Walter Bright]

Andrei Alexandrescu wrote:
> I wish somehow all this nice philosophy about aircraft would somehow 
> found its way in the compiler implementation.

I was referring to the language design, but yes, I think some of it is 
in the compiler implementation. In your criticism, you should also 
realize the Boeing is extremely conservative about adopting new designs. 
D is not conservative in that way at all, we're constantly trying out 
new things, and that means crashes and the occasional blowup on the 
launch pad <g>.

It took about 20 years of flying jet engines in aircraft, and iterative 
improvements, to really work the usability problems out.

I once had an illuminating conversation with the lead engineer of the 
757 cockpit design. I (stupidly) said it was obvious how to design the 
controls. He mildly replied that everything that looked obvious was paid 
for by someone who splattered his brains over the instrument panel, and 
the obviousness of the right way to do it was discovered only later 
after careful analysis.


> Or perhaps it *is* the 
> main cause of the problems with the compielr implementation.  I finally 
> found out why dmd was crashing on my program with nothing but 
> "Segmentation fault":
> 
> assert(puu.is_empty());
> 
> was used in my old code instead of:
> 
> assert(puu.empty());
> 
> This was inside a template class and was enough to have the compiler 
> segfault leaving me with no line and not even file information. Combine 
> that with templates and multiple files and -lib compiling, and you'll 
> see just how pernicious that is. (If you answer and the answer contains 
> "binary search", I'll drop to the ground and start kicking it with my 
> arms and legs. Binary search for where compilation fails DOES NOT WORK! 
> It is search but NOWHERE NEAR binary.)

I agree that the line number thing is a constant problem. It really is a 
load of special cases.


> If you allow me a little criticism, I did notice different pattern which 
> may also be derived from a systematic mechanical engineering approach: 
> there generality could be improved. From the hail of bugs that hit my 
> face on a daily basis, I notice that stuff that works works only for the 
> situations it was tested, and subsequently bug fixes only fix one 
> particular situation, not an entire class of problems. That's why 
> reenactments of bugs are not infrequent. Without having looked at the 
> dmd source, I'd conjecture that it contains in many places a hodge-podge 
> of particular cases instead of consistently looking to nail the general 
> problem. I guess this would be the way to go in mechanical engineering, 
> where restrictions of the natural world make the by-case analysis easier 
> to carry exhaustively.

In my defense, I'll point out that you said that when you did "Modern 
C++ Design" you had similar issues with C++ compilers not working. You 
are writing code right out on the edge, and often over the edge, of what 
has been implemented in the compiler.

I'm not making excuses, but it's often hard to see what the general case 
is until after the special cases are accounted for. Then it's time for 
refactoring can cleanup.

When I implement a new feature, there isn't (by definition) any existing 
body of code that uses it. So I have no test cases, nothing, other than 
what I cobble together. You're often the first person to use the feature 
in a substantive way.

Special cases are an odd thing with computers. What a computer sees as a 
special case a user sees as a generalization, and vice versa. 
Programming languages struggle with this dissonance all the time. For a 
recent example on the n.g., 'void' is a special case to the compiler, 
but a general case to the programmer.

Back in college, a science historian did a nice lecture on how research 
was done. He said that in reading the scientists' notebooks, he found 
that they went all over the place in trying to find a solution. When 
they finally found it, they wrote a paper where they presented their 
activities as a straight line progression from hypothesis to proof, 
whereas the reality of how it actually happened was nothing like that.

I also wish to point out that despite dmd being written in C++, it has 
had very few memory corruption bugs in the last 10 years. (Lars found 
one I introduced with the Mac port.) I attribute that to changing my 
coding style to a way which heads them off, but that wasn't possible 
without long experience with them. The problems you're seeing are with 
the new stuff, not the old stuff.