On 3/31/19 7:30 AM, Andrei Alexandrescu wrote:
> But I don't know any who'd also have the time to embark on this.

s/any/enough/

On Sunday, 31 March 2019 at 11:30:08 UTC, Andrei Alexandrescu wrote:
> I got burned out on writing vision documents (Walter was never a fan so I did them all) because it was difficult to figure their impact. Contributors asked for a vision document. So we started one. Then contributors continued doing what they were doing.

I have to say I find the posts you have made the last few days to be very open and containing a lot of truth. It is very refreshing and inspiring to read. I hope you can find your way again and do what you do best.

On 31.03.19 08:53, Jonathan M Davis wrote:
> Once the range is saved, RefRange is
> pretty useless, because the results of what are done to the copy don't
> affect the original.
> 
> And to use RefRange, you're basically depending on implementation details of
> a particular algorithm and when it chooses to call save and what exactly it
> does with the original before and after calling save - something that is not
> part of the function's API or any guarantee that it makes. 
[...]
> RefRange on the other hand is basically trying to get access to the results
> of the first part of the algorithm prior to the call save (and possibly some
> of what's done to the original after the call to save).

All that also applies to other ranges that have reference semantics.

[...]
> So, while RefRange might be okay in code that's written specifically for use
> with RefRange, in general, it's a terrible idea. And I really regret that I
> got into Phobos. The fact that I did just shows how much less I understood
> about ranges at the time.

RefRange is painted as this big scary monster that ruins everything (Andrei called it "cancer", you call it a "terrible idea"). In reality, it might not be the most useful thing, but it works just as well as other reference-type ranges. Or rather, it would, if it weren't for that pesky opAssign. RefRange.opAssign ruins everything.

On Sunday, 31 March 2019 at 11:30:08 UTC, Andrei Alexandrescu wrote:
> The necessity to work on shared was also present in the January 2015 vision document (https://wiki.dlang.org/Vision/2015H1): "Nail down fuzzily-defined areas of the language (e.g. shared semantics, @property)."
>
> Writing it down doesn't get it done.

Indeed thats why its on the AGM.

> Defining shared properly would take a team with a programming languages expert, a threading expert, and an application expert. (Some roles may be realized within the same person.) I know people within our community with the required expertise.

c.f. DIP1000? I don't think you or Walter are memory safety experts, and despite the issues that occurred with the implementation (and documentation(!)) process (hindsight is 20/20), what you have achieved is quite remarkable: a blacklisted (bad things are disallowed), inductive (if all the the code I call is @safe and nothing I do is on the blacklist, then so am I) model of memory safety that works!

What Manu has (tried to, somewhat unsuccessfully) argue for is the same approach to thread safety with shared: tie the correct use of shared to @safe/@system/@trusted, enforce the correct use of user defined and verified (i.e. @trusted) thread safe primitives. Then shared (as a function parameter attribute) in @safe code becomes a requirement to act in a thread safe manner with that argument under the above framework.

No-one is expecting to get the implementation perfect first time, we will miss important details, and thats OK. We fix them, document them (this is the single biggest problem with the way DIP1000 was developed and the reason PRs were stalled) and move on with the satisfaction that the implementation is better than it was before.

> But I don't know any who'd also have the time to embark on this.

If the foundations can be set out, pre-approved, with sufficient clarity at dconf, then I'm confidant we can get to the point where we can iteratively improve it. Who knows, Timon might implement the whole thing in the hackathon.

I don't think it will be as hard as it seems to get somewhere useful. We already have @safe/@system/@trusted, shared is already a thing (albeit not very useful currently), all we need to do is define the blacklist and how the induction should work. Again, they don't need to be perfect first time.

> I got burned out on writing vision documents (Walter was never a fan so I did them all) because it was difficult to figure their impact. Contributors asked for a vision document. So we started one. Then contributors continued doing what they were doing.

I understood vision documents to set out the intended direction of the DLF, irrespective of what contributors are doing, of course they're going to continue to do what they were doing, that what volunteers do. To me they were more like a politicians promise (apologies for the analogy), a statement of intention, and if it doesn't match up to reality, then its no big deal as long as progress is still being made, the next one is written to take that into account with its projections.

Anyway enough about what they were. What they will become is a byproduct of the minutes of the AGM / quarterly meetings, they will practically write themselves.
If we have more (corporate) participation in them (as I hope) then chances are they will reflect reality to a much high degree of fidelity.

On Sunday, 31 March 2019 at 12:03:30 UTC, Sebastiaan Koppe wrote:

> I have to say I find the posts you have made the last few days to be very open and containing a lot of truth. It is very refreshing and inspiring to read.

At the risk of being negative, I had the opposite reaction after reading his posts. It is clear that he has no interest in being the leader of an open source project. He doesn't want to waste his time with average programmers, he only wants to spend his time working with the best of the best (by some metric) software engineers.

That's his option, of course, but it's as welcoming to new contributors as a rattlesnake pit (on par with Linus but using better language). An open source project leader needs to find ways to bring in new contributors, including some who are below average, and help them find a way to contribute. There needs to be an interest/willingness to think about and participate in all areas of the project, even non-elite things like documentation, newbie guides, tools, and marketing the language.

Open source leader and working on a narrow set of technical issues (like pounding out designs of some sort with best-of-the-best software engineers) have little overlap.

> I hope you can find your way again and do what you do best.

So do I, and he should work on the things that interest him, rather than trying to run an open source project.

On Sunday, 31 March 2019 at 11:30:08 UTC, Andrei Alexandrescu wrote:
> I got burned out on writing vision documents (Walter was never a fan so I did them all) because it was difficult to figure their impact. Contributors asked for a vision document. So we started one. Then contributors continued doing what they were doing.

I suggest you write informal status documents in the wiki instead, on a best-effort basis. Instead of writing a document that's pie in the sky "it would be great to have X in the following 6 months, let's pretend we know we can do it", write something more like "I've been working on X, and I've noticed a lot of little problems with Y. Here's what we could do about it, what I'm trying to do Z but why it might not be enough", etc. Do little updates when possible and motivated. Maybe update it sometimes with links to pull requests that you feel helped with the problems, so others can study them and learn what things are especially welcome, etc. Things like that.

In summary, play to our strengths. D has a small community. Keep it close and cozy, not distant and formal.

On 3/31/19 10:12 AM, bachmeier wrote:
> It is clear that he has no interest in being the leader of an open source project. He doesn't want to waste his time with average programmers, he only wants to spend his time working with the best of the best (by some metric) software engineers.

Good leadership is inspiring people from all walks of life toward doing extraordinary things. Point being, not all need to be extraordinary. Groups of extraordinary people working together do happen, but are rare enough to receive their own phrase - "Gang of Four", "Paypal Mafia", "K&R".

I knew this well before embarking on working on D, and I had no illusion about my own skill being remarkable to start with. So I had no unreasonable expectations going in or staying in.

What was surprising, which I alluded to in another post, is that the advice for improvement I'd dispense was frequently debated and occasionally taken as an offense. For whatever reason, I failed to hold the competence high ground. It's as if there was a samizdat manual by which contributors must do two essential things - antagonize Walter and debate my reviews. Needless to say, my growing testy didn't help one bit. There's this subtle Romanian proverb translated loosely as "it's mighty difficult helping who doesn't want to be helped". (I first heard it thirty years ago in the military and thought it's kind of silly.)

This has led to many thousand yard stare evenings I have yet to recover from.

On 3/31/19 10:47 AM, Luís Marques wrote:
> I suggest you write informal status documents in the wiki instead, on a best-effort basis.

A great idea. Walter has doing this on his twitter account:

https://twitter.com/WalterBright

On Sunday, 31 March 2019 at 15:28:55 UTC, Andrei Alexandrescu wrote:
> There's this subtle Romanian proverb translated loosely as "it's mighty difficult helping who doesn't want to be helped". (I first heard it thirty years ago in the military and thought it's kind of silly.)

Look at this comment as someone pointed out before:

https://github.com/dlang/dmd/pull/8557#pullrequestreview-149952733

Do you think after reading this someone is going to be more inclined to work on a pull request or less inclined? You basically said the entire pull request was useless and that any other pull requests like it should not happen. This does not promote or nurture discussion that leads to understanding, this simply terminates it.

Not sure which is worse between Walter not saying anything and leaving pull requests open for years without any additional comment. Or your comments that you think are "help".

I made a pull request to implement a feature I didn't think was that big of a change. Walter left a response that the change needed a DIP. Then some years later the feature gets added without a DIP. Walter never replied to my comments requesting for clarification. Scheisse like that is why people don't feel like contributing.

On Sunday, 31 March 2019 at 00:18:29 UTC, Andrei Alexandrescu wrote:
> why have the outcomes across the C++ and D communities have been so different?
>
> The answer to this question may unlock the potential of our community.

Isn't suggesting ideas for language features the easy part? As opposed to actually making a formal proposal, teasing out the corner cases, comparing alternatives, getting reviewers to accept it, etc?

If your experience in C++ has been mostly writing libraries and proposing ideas, and your experience in D has been mostly reviewing actual work and dissecting complete proposals, then of course C++ will seem easier to you.

I mean, it's not like the standardization process in C++ is painless. In fact, it's renowned for being a byzantine bureaucracy.