std.experimental Timeline

[Jack Stouffer via Digitalmars-d]

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.