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. ;)

On 08/07/2016 7:55 AM, Andrei Alexandrescu wrote:
> https://wiki.dlang.org/Vision/2016H2 -- Andrei

We really need opRef* implemented in dmd.

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

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).

Also I think, that you treat the Action_List as competition to the VD. 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.
Why not create "THE VISION DOCUMENT" and update it when needed. 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. People would have a go to place looking for pre-approved work. Leading to no more gatekeeper rejection frustration.

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

On Friday, 8 July 2016 at 09:17:14 UTC, Robert burner Schadek wrote:
>
> 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.
> Why not create "THE VISION DOCUMENT" and update it when needed.

I like to think about it as a process. Even if it's not perfect, it forces them to sit down and think about what they've done and how they are reaching their goals.

On 2016-07-07 19:55:51 +0000, Andrei Alexandrescu said:

> https://wiki.dlang.org/Vision/2016H2 -- Andrei


A more "business / managment" view:

If we want to achieve hihger adoption rate of D, which IMO should be the first priority as it's an enabler for a lot of the other things posted, the non-technical aspects are much more important.


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.


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.


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.


Just my 2c here...

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

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

On Friday, 8 July 2016 at 14:01:14 UTC, 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

Not hard:

module stdrust;

alias i8 = byte;
alias u8 = ubyte;
alias i16 = short;
alias u16 = ushort;
alias i32 = int;
alias u32 = uint;
alias i64 = long;
alias u64 = ulong;
alias i128 = cent;
alias u128 = ucent;
alias f32 = float;
alias f64 = double;

On Fri, Jul 08, 2016 at 09:17:14AM +0000, Robert burner Schadek via Digitalmars-d-announce wrote: [...]
> 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.

AFAICT this one is going to take a long time. The current DMD code is quite volatile and internal APIs do change over time. Making it a library would be great but if internals are exposed, it would become a barrier to further development. I don't think we're at the point where we're ready to actually work on this just yet.


T

-- 
Those who don't understand Unix are condemned to reinvent it, poorly.

On Thursday, 7 July 2016 at 19:55:51 UTC, Andrei Alexandrescu wrote:
> https://wiki.dlang.org/Vision/2016H2 -- Andrei

I see that this thread has sparked a lot of "ideas for the future". That's a great outcome but many of them don't belong in this vision document, and in fact some probably deserve mention in the vision doc as "great ideas the leadership won't be funding yet - but feel free to drive it yourself if you feel passionate about it".

I think this is important because it would greatly raise satisfaction with the vision doc, if it was more clear "what it is not".

So I'm wondering if there are ways to improve the structure.

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).

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.