DIP 1031--Deprecate Brace-Style Struct Initializers--Community Review Round 1 Discussion

[H. S. Teoh]

On Sun, Feb 16, 2020 at 12:18:30PM -0800, Walter Bright via Digitalmars-d wrote:
> On 2/15/2020 10:27 PM, H. S. Teoh wrote:
> > What's the point of lightning fast generation of poor quality code?
> 
> The speed of the code generated was competitive with (and sometimes
> ahead of) the other compilers from 1985 to 2000 when I worked actively
> on it. It slowly fell behind after that as I was spending my time on
> the D front end.
> 
> This is not evidence that the code quality of the back end is poor.

Note that I did not say the code quality of the back end is poor. I said
that the quality of the code *generated* by the back end is poor.  And
that's not in an absolute sense, since obviously it's still of the same
quality as it was back in 2000, but it's poor in the relative sense,
compared to the output of modern backends like GDC or LDC.

The problem is that while the rest of the world has marched on since
2000, the DMD backend has remained stagnant.  Effectively, therefore,
it's regressing -- not in the absolute sense of course, but relative to
the rest of the world that has since moved on.  Which means that now
it's a much harder sell to choose the DMD backend over, say, LDC or
GDC's.  As a user, I don't care how good the DMD backend is as long as
its output is inferior compared to alternative backends; obviously I'm
going to choose the backend that gives me better generated code,
regardless of how either backend arrives at it.  Maybe the GDC backend
is garbage in terms of its own code quality (as an example -- I don't
know the GDC backend code), but as long as the code it *generates*
performs faster than the code DMD generates, users are going to choose
it over DMD.


> > Well this is part of the problem: because the code style is old and
> > unfamiliar to most contemporary programmers, you're not going to
> > find many people who would be able to contribute a PR. And those who
> > can may not necessarily be willing to spend the time to do so.
> > Chicken and egg problem.
> 
> There are very, very few programmers out there who understand code
> generation issues well enough to improve things. It has nothing to do
> with the back end being old fashioned. The data structures in it are
> simple and straightforward.
> 
> That said, some people have contributed some good work to the back
> end, but nothing fundamental.

And that is precisely the problem.  While GDC/LDC backends may or may
not have the technical superiority over DMD's backend, what matters is
that people are improving it over time, whereas the DMD backend has been
staying stagnant. It doesn't matter what the reason is -- maybe
programmers are not competent enough to work on the DMD backend, maybe
there's some other reason, but what matters is that there are very few
people actively improving the DMD backend, whereas there are large teams
of people honing the GDC/LDC backends continually.  Effectively,
therefore, the DMD backend is regressing, not in the sense that it's
actually *degrading*, but in the sense that it's lagging behind the
other backends.

No matter how technically superior the DMD code may be, and no matter
how inferior the other backends may be, what the user is going to choose
will be decided by what kind of code is generated, not by what kind of
code the backend is running.  The DMD backend can be superior all it
wants, but if the code it generates is slower than the code produced by
GDC or LDC, then there is really no reason for me to prefer DMD over GDC
or LDC.  Therein lies the rub.


T

-- 
Why are you blatanly misspelling "blatant"? -- Branden Robinson