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.
