Quora: Why hasn't D started to replace C++?

[H. S. Teoh]

On Wed, Jan 31, 2018 at 09:07:39PM +0000, John Gabriele via Digitalmars-d wrote:
> On Wednesday, 31 January 2018 at 20:03:11 UTC, Adam D. Ruppe wrote:
> > 
> > {snip} (well, I tried to get it upstream but I think upstream is a
> > brick wall and not worth trying anymore)
> 
> That is very concerning to hear.

FWIW, here's my POV regarding "upstream", speaking as one who has no
prior (or current!) personal connection with anyone involved with D
development at the time, and who got granted commit access to Phobos
only because one day I and another person whom I do not wish to name
(who was at the time also not connected to "upstream") were complaining
on the forum about lack of response to Phobos PRs, and *somebody*,
presumably Andrei (but this is speculation on my part, as I was never
actually told what happened exactly), decided to hand us the keys to the
kingdom, so to speak, to see what we'd do with it.  I didn't merge
anything for about a month or more afterwards, not out of intimidation
or anything like that, but just feeling unqualified to make decisions of
that sort just yet. I continued submitting PRs like an "outsider" for a
while, and only later began to build up enough confidence to start
merging PRs.

Even today, I contribute to D development purely out of my own interest,
both in terms of technical interest, interest in seeing D improve
because I use it for numerous personal projects, and also some amount of
personal fulfilment in being able to contribute to something bigger than
just my own projects.

The way I see it, is that the majority of PRs that get merged are in the
category of small, incremental changes, things like bugfixes, small
improvements to existing features, the odd useful tool here and there,
that sort of thing.  Larger-scale changes do tend to take a lot more
work (and persistence!) to push through, not because of any active
policy or motive that hinder such changes, but primarily because as a
volunteer-driven project, it's not very often that someone from among
the volunteers would:

(1) Have the time to spend reviewing a large and complicated change;

(2) Have enough expertise in the affected area(s) of the project to feel
    confident enough to make decisions about it;

(3) Have all of the above plus the interest to actually *want* to wade
    into the depths of a large changeset, which implies the commitment
    to continue interacting with the submitter until it's merged or
    rejected, rather than do something else that's (a) more
    self-contained and easier to review, (b) can be done in a short
    amount of time that fits into their current stretch of free time,
    and (c) still contributes something positive to the project.

Large-scale changes do happen every now and then, such as Daniel
Murphy's monumental effort in translating dmd's original C++ source into
D, leading to the bootstrapping compiler we have today.  But these
require a lot more effort and coordination with key decision makers,
usually Walter & Andrei, and it really helps if you can convince one or
both of them to take your side.  A "small fry" like myself wouldn't dare
to push the merge button on changes of this kind of magnitude, since it
could have drastic consequences that I can't foresee due to not having a
full grasp of the full scale of what is being changed. Plus, sometimes
somebody else *did* raise valid points of concern against the PR, so I
would hold off merging until the concern is addressed and that person
approves of the updated change. And in a large changeset, there can be a
large number of such concerns, which requires a lot of back-and-forth
before a decision can be reached.

Anyway, as far as Adam's dpldocs are concerned, the way I see it is this
(and I'm saying this not as someone making the decision, but as a
mostly-disinterested observer): Around the time it was first proposed,
there are already two other competing documentation systems:

- The ddoc system, the original, and still in heavy use at the time, up
  till today;

- Sonke's newer one-page-per-function ddox system (which today has been
  partly integrated, but still not fully the default yet because of
  various issues that I didn't look too much into).

Having 3 different competing documentation systems is really crowded for
this space, so for any of them to stand a chance, it has to be either
already entrenched (ddoc), or else must offer significant advantages
over its competitors.  More importantly, its proponent(s) would have to
convince Andrei or Walter of said significant advantages, since that's
what will tip the scale (obviously, its proponents must believe it has
significant advantages otherwise they wouldn't have proposed it in the
first place -- but the deciding factor is whether Andrei and/or Walter
think likewise).

And IIRC, Andrei had already bought into the ddox system by then (the
process of merging it might have already begun, I'm not 100% certain),
so dpldocs was already starting from a disadvantaged position, whatever
merits it may have on its own.  And I'll be frank that sometimes Andrei
can take some effort to convince, and it takes a certain amount of
dogged persistence (and thick-skin) to get through to him sometimes.
And it doesn't help that he has so much on his plate, and generally
doesn't have enough time to dedicate to all the decisions waiting upon
him to make, so sometimes it can be frustrating trying to get through to
him.

So to get through, dpldocs would need show a major advantage over ddoc
and ddox, and Adam (and whoever else) would need to be persistent enough
to convince Andrei to approve of it, and then it would require the
effort to integrate it into everything else that's currently being used
for generating docs on dlang.org -- since obviously, it wouldn't do for
a new doc system to get merged, only for everyone to find that parts of
dlang.org are now broken, or not working as well as before, or Phobos
doc builds now have new issues, etc..

AFAICT, none of this is any deliberate roadblock or "brickwalling" to
stop alternative proposals from being accepted, but it's mostly just due
to circumstantial situations that arose, for better or for worse, as
part of how D came to be what it is today.  In that sense, I don't blame
Adam from deciding to fork instead -- given the circumstances, that's
certainly the path of least resistance, unfortunate as it is.  With ddoc
still entrenched as the de facto documentation system, and with ddox
already merged and continuing to be improved with the view of becoming
the new default docs (not my personal preference, but that's the
direction it's headed), any alternative proposals would have a pretty
tough uphill fight to get through.  It's unfortunate, but I don't think
it's unreasonable either -- as I said, if it would not bring new,
compelling advantages to the table, then it's pretty hard to justify all
the work it would take to merge it and then maintain it afterwards. At
least, it would be pretty tough to convince Andrei about this.


T

-- 
MACINTOSH: Most Applications Crash, If Not, The Operating System Hangs