On Tue, Apr 02, 2019 at 01:26:34AM -0700, Walter Bright via Digitalmars-d wrote:
> On 4/1/2019 6:11 PM, H. S. Teoh wrote:
> > Had this been posted openly at the time, there might have been a lot less frustration.  This is an area I feel desperately needs improvement.  This repeated lack of communication of this sort of thought process in one form or another is what leads to repeated frustrations and conflicts, because would-be contributors feel like information is being withheld that would have enabled them to better understand what is expected of them.  Even if these were just vague thoughts or a crude outline of what you have in mind, and nowhere near something formal and "presentable", providing partial information is better than no information at all.
> 
> Actually, Andrei and I simply assumed this was obvious. Obviously, it wasn't.

Therein lies the frequent cause of miscommunications: assuming that the other party knows or understands something, which may not necessarily be the case.  Especially when we're talking about random strangers on the internet, who may have had a completely different experience and background as yourself, and therefore in all likelihood understands and sees things differently.  Stating all assumptions up-front helps to bridge this gap.


T

-- 
Ph.D. = Permanent head Damage

On Friday, 29 March 2019 at 21:28:40 UTC, Olivier FAURE wrote:
>
> Seriously, I'm worried that the takeway you're getting from all this is "the community is unreasonable, unlike Rust's community which has a healthy respect for the maintainers". It's not just that. The D community is has a ton of people whose experience writing a PR is "I spent two weeks writing that code, got a comment from Walter six months later that asked to clarify what X did, I added some documentation, and I haven't had any news for a year".

I don't how long you've been around, but this community seems to me as indeed unreasonable and often disrespectful (I've been doing it too at times).

The sheer number of people trolling and wanting to hurt other people personally over the years has been really disconcerting.

We need to attract users who _need_ D to make stuff, contribute back (in time and money), and stop asking random useless things every other day of the week. And the  problem compounded because the abusive behaviour sometimes led to the most langage change!

The problem with D is that it has an "unscalable" community of very demanding people that bring not enough, so like a startup without scale economics it has difficulty to scale.

As a friend working on Eclipse told me, "all things being equal, having users is a liability" so you have to ask them to create more value than being removed.

Something that we do that I think doesn't work is... the lack of a Code of Conduct and a rule of not banning anyone, which opens the gate of small, constant, rampant abuse that can surface at the first occasion.

And something we should do more is put trust into the leadership more because, of all the mistakes they have been accused of, so many of the decisions ended up being the right ones.

On Wednesday, 3 April 2019 at 12:33:38 UTC, Guillaume Piolat wrote:
> The sheer number of people trolling and wanting to hurt other people personally over the years has been really disconcerting.
>

I realize that it's difficult to give examples here without calling specific people out, but without giving examples I have no way to judge what your standard for "trolling and wanting to hurt other people personally" is. That's kind of a pretty hefty accusation to make without the ability to ethically provide evidence. I think either you need to explicitly call people out here or you need to formulate this more leniently, as it stands it's kind of like announcing "several people in this room are psychotic killers, I can't say who, but that's why we need to take urgent action."

It is fundamentally epistemically improper to demand action on weighty evidence that cannot be ethically provided.

On Wednesday, 3 April 2019 at 14:09:49 UTC, FeepingCreature wrote:
> It is fundamentally epistemically improper to demand action on weighty evidence that cannot be ethically provided.

I've been perhaps overstating my point, but no I'm not going to namecall - let's talk about the anonymous accounts.

One prime example is in one message juste above ours.

Once Andrei started saying things remotely uncomfortable for D, one "helpful" anonymous individual posted it to HN. Surely the intent couldn't be positive for D.

It gives the impression it's OK to disrespect the leadership, and that it's OK to shit in the soup.

Such anonymous actions have been going on since the beginning of D times, it gives a baseline upon more respectable personas can act in ways they wouldn't have.

I don't _demand_ anything, one action that would make sense if - in my opinion - to stop anonymity in these forums, and add accountability back.

On Wednesday, 3 April 2019 at 14:09:49 UTC, FeepingCreature wrote:
> On Wednesday, 3 April 2019 at 12:33:38 UTC, Guillaume Piolat wrote:
>> The sheer number of people trolling and wanting to hurt other people personally over the years has been really disconcerting.
>
> I realize that it's difficult to give examples here without calling specific people out, but without giving examples I have no way to judge what your standard for "trolling and wanting to hurt other people personally" is. That's kind of a pretty hefty accusation to make without the ability to ethically provide evidence. I think either you need to explicitly call people out here or you need to formulate this more leniently, as it stands it's kind of like announcing "several people in this room are psychotic killers, I can't say who, but that's why we need to take urgent action."
>
> It is fundamentally epistemically improper to demand action on weighty evidence that cannot be ethically provided.

They seems to come and go, sometimes posing as enthusiastic users who want some specific thing to happen and get all upset when people don't take too kindly to it. Sometimes they impersonate  other community members and stoke the flames.

Unfortunately I don't have any links offhand (I'm madly packing) and have forgotten the names they posted under. The egregious one tend to be deleted from the forum interface (although I think they are still on the mailing lis that backs it).

On 3/31/19 6:25 PM, Manu wrote:
> On Sat, Mar 30, 2019 at 5:45 PM Andrei Alexandrescu via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>>
>> On 3/30/19 2:49 PM, Jonathan M Davis wrote:
>>> This would also be a great opportunity to fix some of the issues with shared
>>> in druntime
>>
>> The problem here is, of course, that nobody knows exactly what shared is
>> supposed to do. Not even me. Not even Walter.
> 
> As an immediate stop-gap, shared must have *no read or write access*
> to data members. Simple. Make that change. Right now.
> Then shared will at least be useful and not embarrassing, and you can
> continue to argue about what shared means while I get to work.
> 
>> One monumental piece of work would be DIP 1021 "Define the semantics of
>> shared". Then people who build with -dip1021 know what to do and what to
>> expect. Now that would patch one of the bigger holes mentioned in the
>> other post.
> 
> Sure. But in the meantime, fix the objective bug with the current
> semantics where you can read/write un-protected data freely. Right
> now. Please for the love of god.

Incidentally Walter and I discussed in the early days the idea that "shared" would offer no access whatsoever aside from a few special functions in druntime such as "atomicRead" and "atomicWrite". Of course, that raised the question how those functions could be implemented - the possible solution being some casts for typing and asm for the needed memory barriers.

In the end we got scared that there was no precedent in other languages, and we could not predict whether that would have been good or bad. The result is the current semantics, which should be a felony in the 48 contiguous US states.

This does not work as a two stages process, though the "stop the bleeding first then come with the new solution" metaphor seems attractive. The main issues being when we break code that people got to work, we need to offer the alternative as well. Another being that the exact kind of things we disable/enable may be dependent on the ultimate solution.

This would be a large effort requiring a strong team. Walter, yourself, and I would be helpful participants but I think between the three of us we don't have the theoretical chops to pull this off. At least I know I don't. We need the likes of Timon Gehr, Johan Engelen, and David Nadlinger (whom I cc'd just in case).

On Thursday, 4 April 2019 at 02:05:15 UTC, Andrei Alexandrescu wrote:
> On 3/31/19 6:25 PM, Manu wrote:
>> Sure. But in the meantime, fix the objective bug with the current
>> semantics where you can read/write un-protected data freely. Right
>> now. Please for the love of god
>
> This does not work as a two stages process, though the "stop the bleeding first then come with the new solution" metaphor seems attractive. The main issues being when we break code that people got to work, we need to offer the alternative as well. Another being that the exact kind of things we disable/enable may be dependent on the ultimate solution.

Well whatever happens I'll be gobsmacked if its not behind an opt in switch.
With that in mind, if Manu gets use out of the stopgap of disabling read/write access, then I think we should implement that ASAP and then listen to whatever he complains about next ;)

> This would be a large effort requiring a strong team. Walter, yourself, and I would be helpful participants but I think between the three of us we don't have the theoretical chops to pull this off. At least I know I don't. We need the likes of Timon Gehr, Johan Engelen, and David Nadlinger (whom I cc'd just in case).

I don't think we are going to be able to do this without iterating on the design and closing holes and nuisances that we discover. I'm not saying that it is a bad idea to design up front as much as we can, but we shouldn't wast time getting hung up on design when implementation can give gains to users and guidance to the design.

On 4/3/19 11:09 PM, Nicholas Wilson wrote:
> On Thursday, 4 April 2019 at 02:05:15 UTC, Andrei Alexandrescu wrote:
>> On 3/31/19 6:25 PM, Manu wrote:
>>> Sure. But in the meantime, fix the objective bug with the current
>>> semantics where you can read/write un-protected data freely. Right
>>> now. Please for the love of god
>>
>> This does not work as a two stages process, though the "stop the bleeding first then come with the new solution" metaphor seems attractive. The main issues being when we break code that people got to work, we need to offer the alternative as well. Another being that the exact kind of things we disable/enable may be dependent on the ultimate solution.
> 
> Well whatever happens I'll be gobsmacked if its not behind an opt in switch.
> With that in mind, if Manu gets use out of the stopgap of disabling read/write access, then I think we should implement that ASAP and then listen to whatever he complains about next ;)
> 
>> This would be a large effort requiring a strong team. Walter, yourself, and I would be helpful participants but I think between the three of us we don't have the theoretical chops to pull this off. At least I know I don't. We need the likes of Timon Gehr, Johan Engelen, and David Nadlinger (whom I cc'd just in case).
> 
> I don't think we are going to be able to do this without iterating on the design and closing holes and nuisances that we discover. I'm not saying that it is a bad idea to design up front as much as we can, but we shouldn't wast time getting hung up on design when implementation can give gains to users and guidance to the design.

I don't think this works for programming language design. In fact I'm positive it doesn't. It's the way we've done things so far.

On 4/4/19 12:24 AM, Andrei Alexandrescu wrote:
> On 4/3/19 11:09 PM, Nicholas Wilson wrote:
>> On Thursday, 4 April 2019 at 02:05:15 UTC, Andrei Alexandrescu wrote:
>>> On 3/31/19 6:25 PM, Manu wrote:
>>>> Sure. But in the meantime, fix the objective bug with the current
>>>> semantics where you can read/write un-protected data freely. Right
>>>> now. Please for the love of god
>>>
>>> This does not work as a two stages process, though the "stop the bleeding first then come with the new solution" metaphor seems attractive. The main issues being when we break code that people got to work, we need to offer the alternative as well. Another being that the exact kind of things we disable/enable may be dependent on the ultimate solution.
>>
>> Well whatever happens I'll be gobsmacked if its not behind an opt in switch.
>> With that in mind, if Manu gets use out of the stopgap of disabling read/write access, then I think we should implement that ASAP and then listen to whatever he complains about next ;)
>>
>>> This would be a large effort requiring a strong team. Walter, yourself, and I would be helpful participants but I think between the three of us we don't have the theoretical chops to pull this off. At least I know I don't. We need the likes of Timon Gehr, Johan Engelen, and David Nadlinger (whom I cc'd just in case).
>>
>> I don't think we are going to be able to do this without iterating on the design and closing holes and nuisances that we discover. I'm not saying that it is a bad idea to design up front as much as we can, but we shouldn't wast time getting hung up on design when implementation can give gains to users and guidance to the design.
> 
> I don't think this works for programming language design. In fact I'm positive it doesn't. It's the way we've done things so far.

Well I'm exaggerating. I mean to say every time we did it that way, the result hasn't been good.

On Wednesday, April 3, 2019 8:05:15 PM MDT Andrei Alexandrescu via Digitalmars-d wrote:
> On 3/31/19 6:25 PM, Manu wrote:
> > On Sat, Mar 30, 2019 at 5:45 PM Andrei Alexandrescu via Digitalmars-d
> >
> > <digitalmars-d@puremagic.com> wrote:
> >> On 3/30/19 2:49 PM, Jonathan M Davis wrote:
> >>> This would also be a great opportunity to fix some of the issues with shared in druntime
> >>
> >> The problem here is, of course, that nobody knows exactly what shared
> >> is
> >> supposed to do. Not even me. Not even Walter.
> >
> > As an immediate stop-gap, shared must have *no read or write access*
> > to data members. Simple. Make that change. Right now.
> > Then shared will at least be useful and not embarrassing, and you can
> > continue to argue about what shared means while I get to work.
> >
> >> One monumental piece of work would be DIP 1021 "Define the semantics of
> >> shared". Then people who build with -dip1021 know what to do and what
> >> to
> >> expect. Now that would patch one of the bigger holes mentioned in the
> >> other post.
> >
> > Sure. But in the meantime, fix the objective bug with the current semantics where you can read/write un-protected data freely. Right now. Please for the love of god.
>
> Incidentally Walter and I discussed in the early days the idea that "shared" would offer no access whatsoever aside from a few special functions in druntime such as "atomicRead" and "atomicWrite". Of course, that raised the question how those functions could be implemented - the possible solution being some casts for typing and asm for the needed memory barriers.
>
> In the end we got scared that there was no precedent in other languages, and we could not predict whether that would have been good or bad. The result is the current semantics, which should be a felony in the 48 contiguous US states.
>
> This does not work as a two stages process, though the "stop the bleeding first then come with the new solution" metaphor seems attractive. The main issues being when we break code that people got to work, we need to offer the alternative as well. Another being that the exact kind of things we disable/enable may be dependent on the ultimate solution.
>
> This would be a large effort requiring a strong team. Walter, yourself, and I would be helpful participants but I think between the three of us we don't have the theoretical chops to pull this off. At least I know I don't. We need the likes of Timon Gehr, Johan Engelen, and David Nadlinger (whom I cc'd just in case).

shared already tries to prevent various read/write operations that aren't guaranteed to be thread-safe. So, it's already gone partially in that direction, and if it's supposed to guarantee any kind of thread-safety, that's the only way that it can go unless it's going to try to insert code that ensures thread-safety - which would mean doing stuff like having mutexes built in to what it's doing so that it knows what to lock and when, and that's not something that's going to work as a low level construct. Even the concept of synchronized classes as proposed in TDPL couldn't go far enough with it to be very useful, because it could only safely cast away the outer layer of shared. I thought that it was pretty clear that the way we were going - and have to go - is to make it so that you simply can't read or write to shared data without either using operations that are guaranteed to be thread-safe or by casting away shared (at which point, the code is @system, and it's up to the programmer to get it right, and that code is properly segregated thanks to how @safe and @trusted work).

I grant you that we really do need the best people we have to look at this at the low level and make sure that it works properly, but I don't see where else we can go with this if we want any kind of guarantees from shared. If we decide that we don't want shared to provide guarantees and that we want to allow shared data to be read and written to regardless of whether the compiler can guarantee thread-safety, then we can do that, but then things that are currently illegal should be made legal (e.g. IIRC, incrementing shared integers is illegal), and at that point, shared is just indicating which variables are shared across threads without actually protecting you at all. That would put it more in line with languages like C++, but it also would mean that it would be a lot less useful for catching bugs.

Either way, what we have right now is halfway in between. It makes some stuff that isn't thread-safe illegal but doesn't make it all illegal, making it a pain to use if you don't cast away shared like you would need to if all operations which weren't guaranteed to be thread-safe were illegal but simultaneously failing to actually protect you and guarantee that the code with operations that are potentially not thread-safe is @system. It looks to me like it has to go one way or the other. Either make it all illegal, thus requiring code that deals directly with synchronization mechanisms to use casts and be @trusted - or make all of the read/write operations on shared objects legal and just restrict it in that it can't be converted to or from thread-local without a cast.

- Jonathan M Davis