Dicebot on leaving D: It is anarchy driven development in all its glory.

[H. S. Teoh]

On Fri, Aug 24, 2018 at 09:12:40PM +0000, Meta via Digitalmars-d wrote:
> On Friday, 24 August 2018 at 17:12:53 UTC, H. S. Teoh wrote:
> > I got bitten by this just yesterday.  Update dmd git master, update
> > vibe.d git master, now my vibe.d project doesn't compile anymore due
> > to some silly string.d error somewhere in one of vibe.d's
> > dependencies. :-/
> 
> While we're airing grievances about code breakages, I hit this little
> gem the other day, and it annoyed me enough to complain about it:
> https://github.com/dlang/phobos/pull/5291#issuecomment-414196174
> 
> What really gets me is the actual removal of the symbol. If it had
> been left there with a deprecation message, I would've caught the
> problem immediately at the source and fixed it in a few minutes.
> Instead, I spent an hour or so tracing "execution" paths through a
> codebase that I'm unfamiliar with to figure out why a static if branch
> is no longer being taken.

Ironically, I was the one who pushed the merge button on that PR. :-/
Mea culpa.

But we had discussed this particular change at length before, and it was
clear that there was no clean way to effect the change; every approach
would lead to a mess. I forget the details now, but I think Jonathan's
approach was the least of the evils among the options we had.

Though you do have an extremely good point about deprecating it first,
or somehow warning the user in some way, so that when things do break,
the solution is clear and doesn't require hours of tracing through 3rd
party code.  I'm not sure if it was actually possible for deprecation to
work on this particular change, but in any case, we should have tried
harder to communicate the cause (and possible solution(s)) of the
breakage to users.


> On the topic of this thread... I was a bit confused with Dicebot's
> decision to leave at the time, because he seemed to like dip1000 but
> then later had a heel turn and left. Looking back through newsgroup
> threads, it seems like it was mostly that he disagreed with the
> project management side of things (which he also brings up in his
> article); an incomplete version of the feature being merged with code
> in the main branch having to be adjusted to support it. People have
> complained about it before, and it's distressingly common in D. Why
> it's not done in a feature branch and then merged in, I don't know,
> but I do agree with his objections.

I think it's clear by now that most of D's woes are not really technical
in nature, but managerial.  I'm not sure how to improve this situation,
since I'm no manager type either.  It's a known problem among techies
that we tend to see all problems as technical in nature, or solvable via
technical solutions, when in reality what's actually needed is someone
with real management skills.  Hammer and nail, and all that, y'know.

Unfortunately, we techies also tend to resist non-technical
"interference", especially from non-techies (like manager types). I used
to have that attitude too (and probably still do to some extent), and
only with age did I begin realizing this about myself.  It's not an easy
problem to fix in practice, especially in a place like here, where we're
driven primarily by the technical aspects of D, and for the most part
outside of any financial or other motivations that might have served to
moderate things a little.


T

-- 
Some days you win; most days you lose.