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.