On Saturday, 18 August 2018 at 13:33:43 UTC, Andrei Alexandrescu
wrote:
where are the best leverage points in making the D language
more successful.
I'm still internalizing the article and thinking about how it
applies to the "D system", but I've always thought facilitating
the incorporation of GDC into GCC to be the single most
accelerating thing we could do to gain more adoption. It
somewhat fits into *7. The gain around driving positive feedback
loops*.
But there's risk associated with that. Walter has often said
that "build it and they will come" is a Hollywood myth, but I
disagree. Part of the reason why D hasn't achieved mass
adoption, isn't because it's not marketed well, but because it
has a number of flaws. Most of us see the *potential* of D, and
are able to look past the flaws, with the faith (hopefully not
misplaced) that they will one day be addressed. Others only see
the flaws and the appeal of other programming languages with more
resources, better management, more talent, and especially more
velocity toward their goals.
I often worry that if we encourage adoption, before we have
something worthy of adoption, we'll only leave users with a bad
taste in their mouth [0]. I've already seen a number of people,
some major contributors, leave D for greener pastures. Most of
the contributors that built the D runtime and did the majority of
bug fixing in the compiler are gone now. At this point in time,
I can only recommend D professionally to teams that are risk
takers, have the aptitude to solve their own problems, and have
the resources and willingness to be D contributors.
We should probably be looking more for leverage points to help us
better capitalize on the resources and talent we have and bring
in more. Unfortunately I'm seeing an over-correction in *8. The
strength of negative feedback loops, relative to the impacts they
are trying to correct against*. As we try to get contributors to
focus on the things that matter (at least to the powers that be),
we frustrate them until they close their pull requests or just
give up [1] [2].
It took me a few years to find my "in", and I'm still not really
"in", but I learned that the *little things* that some consider a
distraction are how people get started contributing to D. I've
often said that we actually don't need more contributors; but
more reviewers. There's a catch to that, though; they're not
going to become reviewers if they can't first become
contributors. So perhaps, I need to correct my perspective.
So, I'll close with this: We should probably be more welcoming
to those willing to contribute, let them work on the little stuff
that's important to them, throw them a bone or two, review their
pull requests in a timely manner, etc... I think those
contributors will eventually become our reviewers, and then they
will eventually lessen the burden so veterans can focus on the
things that they think are higher priorities. This is a positive
feedback loop. Help people become positive contributors, and
those contributors will eventually help the next generation. I
think there are a few little things the leadership, especially,
can do to prime that pump, starting with being more active,
helpful, and gracious with things that are currently sitting in
the PR queue. Though it's a two-way street, and some
contributors could also be more cooperative also.
Walter and a few others have been quite gracious to me [3] [4].
I've tried to pay that forward and help other contributors find
their "in", but I'm still not able to review and make decisions
about many things, so I'm only of limited help. I don't think
others have been treated as well.
Mike
[0] - https://issues.dlang.org/show_bug.cgi?id=14100 - Link in
that issue no longer exists, but let's just say the user wasn't
happy with D
[1] -
https://github.com/dlang/dmd/pulls?q=is%3Apr+author%3Amarler8997+is%3Aclosed
[2] - https://github.com/dlang/dmd/pull/8378
[3] -
https://github.com/dlang/dmd/pull/7395#issuecomment-349200847
[4] -
https://github.com/dlang/dmd/pull/7055#issuecomment-320006283
