On 07/08/2016 01:04 PM, Jack Stouffer wrote:
> 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.

They are useful in the sense that people may see the goal and come up with their own ideas on how to achieve it. -- Andrei

On 07/07/2016 03:55 PM, Andrei Alexandrescu wrote:
> https://wiki.dlang.org/Vision/2016H2 -- Andrei

I have integrated https://wiki.dlang.org/Walter_Andrei_Action_List#Walter_and_Andrei.27s_Action_List within https://wiki.dlang.org/Vision/2016H2.


Andrei

On 07/07/2016 10:33 PM, Brad Roberts via Digitalmars-d-announce wrote:
> On 7/7/16 12:55 PM, Andrei Alexandrescu via Digitalmars-d-announce wrote:
>> https://wiki.dlang.org/Vision/2016H2 -- Andrei
> 
> In the release management section, I'd like to see some priority placed
> on regressions.  There was a time that releases were held until those
> where addressed.  It was only a couple releases, but the list did get
> down to just 1 that was deemed not blocking (I don't remember the details).

While it's true that we don't block releases b/c of regressions any longer, I wouldn't want to change this. The old rule led to annoying distortions, where regressions were sometimes (not that often) misused to raise awareness for a particular problem, and often got fixed sloppily to no longer block the release w/o following up.

It's true though that we should prioritize regressions fixing more.

On 7/8/2016 6: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.

I have yet to find any engineering product in any field that doesn't have open issues. A more practical question is does the product deliver enough value to make up for its deficiencies.


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

It's a great idea, do you want to work on it?

On 7/8/2016 7:01 AM, Eugene wrote:
> please add some features from Rust: primitive type aliases, like i8, u8, u32,
> and so on

http://dlang.org/phobos/core_stdc_stdint.html

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

Promote video tutorials? :)

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

This list is full of good and worthy stuff, but is very long. Most of this won't be done in 2H16, so calling these "2H16 priorities" is misleading, and doesn't give a good impression. For someone who really know where the language is headed, there's no sense of what will really be done in the next six months, what is in progress and might be done, and what stuff is just wishful thinking. The fact that so much is just copied over from last half says it all.

Some of these, especially the marketing, are evergreen tasks. ("Promote books and articles"). If there's something concrete you have in mind for 2H16 say it, otherwise, it belongs somewhere else.

This is a really good long-term vision list, and it might be better labeled that, with different items slated for expected realization (2H16, 1H17, "Who knows?"), etc. (Links to associated bug reports would be useful too, so we know what's being worked on.)

In general, I feel like a list like this should actually be achievable. There's a silly, but still useful, business thing called "S.M.A.R.T." goals: Specific, Measurable, Attainable, Realistic, and Timely. This ain't that.

On 7/8/16 6:36 PM, Carl Vogel 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
>
> This list is full of good and worthy stuff, but is very long.

It's the right length. It includes things we actively work on along with a few items we keep an eye on and others we believe are important and count on other folks to be on. -- Andrei

On 09/07/2016 5:08 AM, Andrei Alexandrescu wrote:
> 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

As in your solution to ref counting.
We have already discussed this :)

On 2016-07-08 18:07:39 +0000, Andrei Alexandrescu said:

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

IMO D has a lot to put on the table, and that should work seemlessly. So, the elevator-pitch for D is possible. However, it's a personal taste what is "better than..." and if helps or not.

My rule of thumb, after many years of experience is, that I'm very conservative when it comes to base technology stuff. Less is more, slow moving & high quality is better than fast & fancy.


>> 2. Case-Studies: ...
> 
> There are some. I'd love to see such.

Are these listed somewhere?


>> 3. How about a "D Master" online certificate? scrum.org is doing that. ...
> Will keep that in mind, although there's some stigma associated with this.

Which? That these things are of low quality?

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