On 07/07/2016 04:39 PM, H. S. Teoh via Digitalmars-d-announce wrote:
> On Thu, Jul 07, 2016 at 03:55:51PM -0400, Andrei Alexandrescu via Digitalmars-d-announce wrote:
>> https://wiki.dlang.org/Vision/2016H2 -- Andrei
>
> Under "raising participation", are there any concrete steps that can be
> taken to realize this goal? Given that last quarter we failed to achieve
> the target number of PRs, it seems that specifying more concrete steps
> would be a first step to actually reaching the goal, instead of merely
> hoping things would somehow just come together.

I think the most important concrete step is to find more reviewers, which is already in the document. As to how to do that, I'm not sure. -- Andrei

On Friday, 8 July 2016 at 16:55:54 UTC, Andrei Alexandrescu wrote:
> I think the most important concrete step is to find more reviewers, which is already in the document. As to how to do that, I'm not sure. -- Andrei

To be blunt, the vision (and goals in general) are kind of useless without a plan to achieve them.

On 07/07/2016 05:48 PM, Seb wrote:
> On Thursday, 7 July 2016 at 19:56:29 UTC, Andrei Alexandrescu wrote:
>> On 07/07/2016 03:55 PM, Andrei Alexandrescu wrote:
>>> https://wiki.dlang.org/Vision/2016H2 -- Andrei
>>
>> Please provide feedback. We'll make a couple more passes before this
>> is complete. Thanks! -- Andrei
>
> I agree that you should explain how it is planned to achieve "Raising
> participation". Here's an idea:
[snip]

Added. Thanks! -- Andrei

On 07/07/2016 06:06 PM, qznc wrote:
> On Thursday, 7 July 2016 at 19:56:29 UTC, Andrei Alexandrescu wrote:
>> On 07/07/2016 03:55 PM, Andrei Alexandrescu wrote:
>>> https://wiki.dlang.org/Vision/2016H2 -- Andrei
>>
>> Please provide feedback. We'll make a couple more passes before this
>> is complete. Thanks! -- Andrei
>
> Wrt "Improve organization": I see a lot of potential in automating more
> stuff.
>
> * Have a bot for pinging reviewers like Facebook's mention-bot or Rust's
> highfive
>
> * Check various Phobos guidelines like "every function must have an
> example"
>
> * Use dfmt on Phobos (I know this is much bigger than it sounds)
>
> * Compile all dub packages for testing
>
> * Track performance and memory use
>
> * Have a blog post about the automation we already have (autotester
> deserves some applause once in while)
>
> The nice thing about automating stuff is that it usually pays off the
> investment in the long run. ;)

Done. Thanks! -- Andrei

On 07/08/2016 12:00 AM, rikki cattermole wrote:
> On 08/07/2016 7:55 AM, Andrei Alexandrescu wrote:
>> https://wiki.dlang.org/Vision/2016H2 -- Andrei
>
> We really need opRef* implemented in dmd.

What is that? -- Andrei

On 07/08/2016 02:54 AM, Johannes Pfau wrote:
> Am Thu, 7 Jul 2016 15:55:51 -0400
> schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:
>
>> https://wiki.dlang.org/Vision/2016H2 -- Andrei
>
>
>> Safety and Memory Management
>
> Btw: You said #15951 (Inefficiencies in struct initialization) is a
> blocker for RCStr. I've started some basic optimizations in GDC, but we
> can't merge this code as long as the spec doesn't even mention = void
> initialized fields.
>
> Would be great if you and or Walter could take the time to add 3-4
> sentences to the spec answering these questions
> https://issues.dlang.org/show_bug.cgi?id=15951#c4

We can address that but probably not part of the vision. -- Andrei

On 07/08/2016 05:17 AM, Robert burner Schadek wrote:
> On Thursday, 7 July 2016 at 20:44:05 UTC, Andrei Alexandrescu wrote:
>> On 7/7/16 3:55 PM, Andrei Alexandrescu wrote:
>>> https://wiki.dlang.org/Vision/2016H2 -- Andrei
>>
>> In the next pass I will integrate Walter_Andrei_Action_List
>
> I'm quite underwhelmed by the Vision Document (VD). I think that is
> because it is a biyearly VD, and IMO in half a year nothing really
> visionary can be done for D (because D is already pretty awesome and
> pushing the envelope takes a lot of time).

It seems to me six months is a sweet spot. Large companies such as Google and Facebook also use a six-months horizon because it's long enough to avoid micromanagement hysteria and short enough to be verifiable and accountable. Yes, I do have a vision for a longer horizon, but it's too vague to be useful - "D will be a major programming language by 2020".

> Also I think, that you treat the Action_List as competition to the VD.

I consider it competition with other things that Walter and I need to worry about. Walter put it cleverly: you can't add more administration without administrators.

A semestrial vision document summarizing our outlook and intentions is about as much as we can bear. A very nice collaborator offered to help with the vision doc but got busy with other things. He had a good quip about us being always late with the vision updates: "If we worked at a company we'd be all fired."

My days in the past few months were as follows:

"I think I can do containers as well as I can do ranges, let me work on that."

"Container nomenclature is exploding! Cool, there's this great Big-O attributes idea on the forum, let me write a library for it"

"Crap, DConf stuff DConf stuff DConf stuff"

"Hey, let's start with a simple container so how about RCStr"

"Urgh, more conferences and gigs but hey it's for the sake of D and the Foundation coffers"

"Argh, Foundation taxes are due"

"Oops, can't let checkedint happen but I can't criticize without proposing an alternative so forget RCStr and let me work on that"

"Argh, I need to work on the nonprofit application"

"Uhm, here's the lawyer review with questions about the nonprofit application"

"Ehm, here's the accountant review with more questions about the nonprofit application"

"Yowzers, it's July 5th and we're late with the vision document"

And so it goes. (Don't even get me started about email.) There are days at the end of which I realize I've been spinning my wheels but got not one line of code written. I'm not complaining, it comes with the territory! Administering one more document? I'd rather avoid it.

> If you don't, even better but consider this:
>
> You create a VD roughly twice a year. You have to compare it with the
> last VD and see what was done. That is a lot of overhead IMO.

Tracking of past performance in comparison with the plan is probably the best and single most important thing about the Vision documents. If we just issued some thoughts every six months and then let them flap in the wind, no tracking no care no nothing - how would that be any better?

> Why not create "THE VISION DOCUMENT" and update it when needed.

It seems the kind of document you're thinking of is a webpage.

> You
> would be able to add long term visions like "Awesome Container Library
> using Allocators", then add subpoints to it like "<strikethrough>Create
> Allocator library</strikethrough>" (strikethrough because it is already
> done). We could then link the relevant forum threads to the points and
> subpoints, discussing the work item.

Would trello help with that kind of stuff?

> People would have a go to place
> looking for pre-approved work. Leading to no more gatekeeper rejection
> frustration.

I don't think preapproved work would lead to less rejection. Rejection is of work of insufficient quality, not of work that has not been preapproved. Conversely, preapproval does not guarantee any work will be actually approaved.

> Additionally, I think that the vision for phobos is really weak, no
> mentions of containers, xml, (si)-units, unit-testing (framework),
> benchmarking, blas, json ... .

Added.

> I'm not the much in the DMD process, but what about making the frontend
> a library and being able to select the backend at the time of
> compilation, as shortly mentioned at DConf. I bet there are a lot of
> subpoints to that as well.

Added.


Thanks!

Andrei

On 07/08/2016 09:51 AM, Robert M. Münch wrote:
> 1. Fixing (all) bugs before doing new things: If I look as a CTO, CIO or
> CEO on D I the first thing I ask is: "Are they doing a lot of new stuff?
> And if, is this thing / last releasae that bullet proof stable that
> there are not annoying open issued?" Any other answer then "yes" would
> get my "no" to use D.

This needs to be balanced with the zeroth thing you ask, which is: "how does it help us with our work better than the competition?" We're not working on many new things, but we do work on things that impact that question.

> 2. Case-Studies: Yes, we have a lot of projects and things going on etc.
> However, beside the "audio plug-in" I'm not so much aware of any D
> products. This even becomes harder to market if there are backend
> use-case / success stories. I thin it makes sense to show, what D has
> been used for, what the advantages are (faster, less cost, better
> maintainability) and how to adopt it.

There are some. I'd love to see such.

> 3. How about a "D Master" online certificate? scrum.org is doing that.
> You have to go through a pretty hard online exam and reach a certain
> point level to become a "Certified Scrum Master". Yes, it might be a bit
> early to think about his line, but IMO better early then late. It just
> shows, that D is taking care about all the non-technical stuff as well,
> which is a decision point for companies.

Will keep that in mind, although there's some stigma associated with this.


Andrei

On 07/08/2016 10:01 AM, Eugene wrote:
> On Thursday, 7 July 2016 at 19:55:51 UTC, Andrei Alexandrescu wrote:
>> https://wiki.dlang.org/Vision/2016H2 -- Andrei
>
> please add some features from Rust: primitive type aliases, like i8, u8,
> u32, and so on

No need. -- Andrei

On 07/08/2016 12:04 PM, Andrew Godfrey wrote:
> 1) A link to that action list, placing it in context relative to this
> doc, and encouraging people to add their ideas like "rust aliases" there
> instead of here. (Or maybe you have a better place for this, like a
> forum where such requests are discussed first).

I'm all for a community-maintained wishlist linked from the vision document. Please initiate one.

> 2) A link to a longer-term vision doc. The question I posted recently in
> "general", about the evolution of the language, is the kind of thing I
> would want to see answered there. Another kind of thing is anything
> "long term strategic" that isn't a priority right now - e.g. pain points
> for new adopters that "we can't work on yet" (e.g. "there are 3
> compilers, and many practitioners end up installing at least 2 of
> them"). And generally, I'd like a place that sets long term
> expectations, e.g. the rate of future deprecation of existing features
> in the language and in Phobos.

I'm not sure what a longer term vision document would be. For me that's by definition http://dlang.org :o). -- Andrei