On Saturday, 2 January 2016 at 04:47:55 UTC, Jonathan M Davis
wrote:
Having another review for something like
std.experimental.logger before it gets merged into Phobos makes
sense, because it would allow us to have an open discussion on
anything that needs to be changed now that folks have been
using it. And if it's ready to go (potentially decided by a
vote), then we could merge it. But without that review, the
only stuff that will have changed is stuff that gets reported
in bugzilla or that a Phobos dev specifically decided to
change. If we want to actually find out how well it's been
working for folks, then we need a way to get feedback based on
actual usage and discuss it. Another review doesn't necessarily
have to be the way that we do that, but it's probably the best
mechanism that we have.
Yeah, unfortunately there is very little communication with a
large portion of end users besides comments on reddit and
bugzilla reports. I don't count people who post in general
because they are largely a self selected group of people who like
D enough to participate in the forum, and so we all have a bias.
After doing a search on GitHub for repos that were already using
std.logger, I found a lot of them were people who post here. Not
that good ideas for fixing things can't come out of this forum,
but IMO there are just not enough people on here for some of the
more obscure of the bad ideas to come to the surface that only
show themselves after a lot of stress is put on something, plus
the bias mentioned earlier.
A good example of this problem is the issue that Sociomantic has
with Phobos (I'm going off their 2013 and 2014 Dconf talks, so I
apologize if some info is wrong). People were always complaining
about Phobos use of the GC, so the Phobos' maintainers solution
was to change things to stack allocation with lazy ranges and the
like. But it turns out that that was completely missing the mark.
Sociomantic uses a lot of fibers so their stacks are rather
small, and so they still couldn't use Phobos. The problem wasn't
necessarily the GC allocation, it was a lack of choice in
allocation, which is a very different problem. Thankfully Andrei
then wrote std.allocator which could solve the problem, but that
just goes to show how an entire community of people can miss what
the root cause of an issue is.
Going back to what I said about a lot of the repos being from
people who post here, I think this shows an unwillingness from
the normal user to import from std. experimental. Paraphrasing
someone else's comment on here (I forget who) "importing from
std.experimental is asking for trouble because you're essentially
importing a ticking time bomb". And really, I can't argue with
this mentality. So this is another block on potential feedback
from users about bad ideas.
As it see it, there are three things that can be done to mitigate
these issues:
1. Do the review for final inclusion, as mentioned before
2. Make the inclusion of modules into std.experimental more of an
event
I knew about PEP 484 way before it was accepted, because I am a
professional Python programmer and I browse /r/Python and it was
posted there. The review threads should have the same media blast
as a D release.
3. Gratuitous use of the deprecation -> undocument -> remove cycle
This is the more effective of the two options, because the first
idea still has the bias and the lack of interest in experimental
problems.
Bad ideas are going to slip through the cracks. The best thing to
do IMO is to get rid of them ASAP as to minimize the damage done.
When very compelling evidence is given that an idea is bad and
should be replaced with something else, as soon as the
replacement is ready, the cycle should start. I believe this is
the best way to mitigate the damage from lack of eyes on a
problem.
