On Tuesday, 10 February 2015 at 06:22:51 UTC, Andrei Alexandrescu
wrote:
Well I have to say something.
Great, lets debate :P
This proposal is a good example of a cultural lore we should
unlearn: high-churn, low-impact changes.
https://github.com/D-Programming-Language/dlang.org/pull/896 is
another example. Meaning changes with a large surface that
rewire vast areas, yet result in only dingy improvements.
The main problem with these is they're easy to argue in favor
of. Yes, an aggregate repository will make certain things
easier. I'm unclear on the relative advantages and
disadvantages, but I have no doubt Dicebot has some good
arguments loaded already. On that pull request, yes, searching
the language definition separately is a nice thing to have.
It is a delicate matter. Yes, spreading over less important
issues is harmful for focusing on core ones. But the same time
having many small issues unresolved harms the contribution
culture as those keep annoying people over and over again.
In this specific case I didn't take go at this because I was
bored and wanted to do _something_. It was because problem with
lack of reliable standard layout kept appearing every time we
wanted to improve build tools and release automation. It was
because I was annoyed that I still can't test Phobos pull
requests on Windows machine even despite getting one - because
setting up a dev environment is just too different between
platforms.
There is a great value in rejecting or delaying controversial
changes if those don't improve on core areas. But with no real
controversy (is there one for this proposal?) it is simply
rejecting work available for free.
Yet, even after executing e.g. the unified repository to
perfection and after everything was said and done, we're
like... how much better than we were? What pain points did we
fix? What is the impact?
Probably something that's neither important nor urgent.
It had good enough importance/effort _ratio_. Low-hanging fruit
how you tend to call it.
Yet we do have matters that are important and urgent. We want
to improve Phobos' take on memory allocation. Yet not one soul
is working on RefCounted. Few know even what needs to be done
of it. Why? Why are so many of us dedicating so much energy to
tweaking what already works, instead of tackling real problems?
Problems that e.g. - pardon my being pedantic - are in the
vision document?
This proposal directly addresses two of vision document points -
"Improve the brand" and "Raise participation" by trying to
minimize entry barrier for D development.
At the same time stuff like RefCounted is a mess. I have no idea
how to do something useful about it without language changes. I
disagree with all your proposals on topic. I don't actually need
solution for that issue in my daily D coding. Do you honestly
expect me to spend any effort at all on it simply because you
mentioned that in vision doc? Seriously?
Don't get me wrong. It's quite likely a unified repo would be
nice. As would be a separate directory for the language
definition. But it's just not what we should be on right now.
This culture of riding the stationary bike faster and faster
must change. We must hop on the real bike and get to pedaling.
I do what I feel needs to be done. You are free either reject or
accept it. But please don't tell me how I should manage my own
spare time. If you want cultural change - lead by example.
