OT: 'conduct unbecoming of a hacker'

[Laeeth Isharc via Digitalmars-d]

On Thursday, 11 February 2016 at 05:31:54 UTC, tsbockman wrote:
> On Thursday, 11 February 2016 at 04:59:16 UTC, Laeeth Isharc 
> wrote:
>> On Thursday, 11 February 2016 at 04:54:15 UTC, tsbockman wrote:
>>> True. Just pointing out that for certain recurring issues, 
>>> the reason that people have fallen back to grumbling is 
>>> because some DIPs *did* get written, but were rejected for 
>>> vague, non-constructive reasons, with no (workable) 
>>> alternative being offered.
>>
>> Which ones, out if interest ?  And in your opinion were they 
>> thought through ?
>
> Specifically, DIP69 and its predecessors, which propose a 
> Rust-inspired lifetime and escape analysis system as a solution 
> to many of D's memory model woes.
>
> It seemed (and still seems) like a good solution to me, but I 
> recognize that I am insufficiently experienced and 
> knowledgeable in the relevant areas to deserve a vote in the 
> matter.
>
> So, I'm not necessarily saying that it should have been 
> accepted - but I can definitely understand how frustrating it 
> is for those who worked on it over the course of several months 
> to have it rejected (as far as I can tell) simply because it is 
> "too complicated". This is non-constructive in the sense that 
> it is a subjective judgment which does not point the way to a 
> better solution.
>
> As of today, the "Study" group for safe reference-counting 
> doesn't appear to be going much of anywhere, because Walter and 
> Andrei have rejected the DIP69 approach without having a real 
> alternative in hand. (DIP77 seems better than nothing to me, 
> but has not been well-received by those in the community who 
> are most invested in, and most knowledgeable of, memory 
> management issues.)
>
> In the spirit of the original post, perhaps what is needed is 
> simply for someone to fork DMD and implement DIP69, so that 
> people can actually try it instead of just imagining it. That's 
> a lot of time and effort to invest though, knowing that your 
> work will most likely be rejected for purely subjective reasons.

Beyond my pay grade, but looks to me like study group is devoted 
to just this kind of question and in response to observation that 
this is something very important to get right and very difficult 
the discussion is beginning with a simpler but important (there 
were some stats on chrome that were quite shocking) problem of 
how to do RC strings.

If there's one area where you shouldn't just accept patches this 
surely must be it !  And I don't see the people that are 
grumbling participating in the study group...