www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Vision document for H2 2016

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
https://wiki.dlang.org/Vision/2016H2 -- Andrei
Jul 07 2016
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jul 07 2016
next sibling parent reply Seb <seb wilzba.ch> writes:
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: Create an outreach/PR team, with the following tasks a) "Recruitment" --------------- - Issue official press releases from the D foundation for major milestones and releases - Improve the newcomer experience (aka your first five minutes) - Find ways to inspire developers to get more in touch and inspire their community - Find sponsors/members organizations for the D foundation once it's official - Help and encourage others to create online course & learning material about D - Reach out to interested universities and assist them in their leading role See also: http://dlang.org/areas-of-d-usage.html#teaching b) Brand awareness ------------------ - consider to use the new design from the DConf16 - provide (or better: sell) small branding items (stickers, posters, T-shirts, ...) - make the #DlangMan culture more mainstream (atm it's mostly Japanese) Another main point that I couldn't see at the moment is: User experience --------------- - better error messages & diagnostics (e.g. DIP83) - afaik macOS still doesn't show line numbers - create a Dlang survey (like the Rust survey) for feedback (e.g. with PR group from above)
Jul 07 2016
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jul 08 2016
prev sibling next sibling parent reply qznc <qznc web.de> writes:
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. ;)
Jul 07 2016
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jul 08 2016
prev sibling parent reply Carl Vogel <carljv gmail.com> writes:
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.
Jul 08 2016
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jul 08 2016
prev sibling next sibling parent reply "H. S. Teoh via Digitalmars-d-announce" writes:
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 "safety and memory management", what about adding "plug existing known loopholes in safe"? Recently Walter has been fixing a series of compiler bugs related to safe, which is a very promising development, but we're not quite there yet: https://issues.dlang.org/buglist.cgi?keywords=safe&list_id=209407&resolution=--- The safe cheesegrater still has (quite) a few more holes to plug. T -- Gone Chopin. Bach in a minuet.
Jul 07 2016
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/7/16 4:16 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 "safety and memory management", what about adding "plug existing known loopholes in safe"? Recently Walter has been fixing a series of compiler bugs related to safe, which is a very promising development, but we're not quite there yet: https://issues.dlang.org/buglist.cgi?keywords=safe&list_id=209407&resolution=--- The safe cheesegrater still has (quite) a few more holes to plug.
Added: "Fix all errors in language design and implementation that allow unsafe behavior in safe code." Thanks! -- Andrei
Jul 07 2016
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/7/2016 1:16 PM, H. S. Teoh via Digitalmars-d-announce wrote:
 Recently Walter has been fixing a series of compiler bugs related to
  safe, which is a very promising development, but we're not quite there
 yet:

 	https://issues.dlang.org/buglist.cgi?keywords=safe&list_id=209407&resolution=---

 The  safe cheesegrater still has (quite) a few more holes to plug.
Most of those are resolved. Here's a better link: https://issues.dlang.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&keywords=safe&keywords_type=allwords&list_id=209410&query_format=advanced 19 of which are in DMD, down from around 40 a month ago. The remainder are mostly due to 'scope' not being implemented.
Jul 07 2016
prev sibling next sibling parent reply Brad Roberts via Digitalmars-d-announce writes:
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).
Jul 07 2016
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/7/16 4: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).
Added a sentence: "Regressions should be paid utmost attention." Thanks! -- Andrei
Jul 07 2016
prev sibling parent Martin Nowak <code+news.digitalmars dawg.eu> writes:
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.
Jul 08 2016
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/7/16 3:55 PM, Andrei Alexandrescu wrote:
 https://wiki.dlang.org/Vision/2016H2 -- Andrei
In the next pass I will integrate https://wiki.dlang.org/Walter_Andrei_Action_List#Walter_and_An rei.27s_Action_List within the vision document. We're already stretched thin organizationally, and need to cut down on overhead and bureaucracy. Last thing we want is yet another document to maintain. -- Andrei
Jul 07 2016
parent reply Robert burner Schadek <rburners gmail.com> writes:
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.
Jul 08 2016
next sibling parent jmh530 <john.michael.hall gmail.com> writes:
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.
Jul 08 2016
prev sibling next sibling parent "H. S. Teoh via Digitalmars-d-announce" writes:
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.
Jul 08 2016
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jul 08 2016
next sibling parent reply Robert burner Schadek <rburners gmail.com> writes:
On Friday, 8 July 2016 at 18:04:16 UTC, Andrei Alexandrescu wrote:
 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".
But we are not Facebook or Google. And I bet even they have some mid/long-term visions.
 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.
IMO that is wrong, well not so much wrong as misleading. We don't just need more administration because we need more administration. We need more administration or lets say more management and delegation to get things done.
 A semestrial vision document summarizing our outlook and 
 intentions is about as much as we can bear. ....
Well, you and Walter graduated from engineering to management. That, reviewing other peoples work and delegating is your job now. Like it or not.
 Would trello help with that kind of stuff?
Yes if anybody had access to the trello and would want to use yet another tool. I think that is unrealistic. But we already have the wiki and github. So extending the VD to rolling VD in the wiki is the way to go IMO. Or move everything to github including bugtracker and start using milestones etc. Again, IMO in the long run a long term VD, updated on a need to basis with subtasks will save you work.
 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.
Considering the current event is disagree. Maybe preapproved work is not the right wording. Maybe preapproved designs.
Jul 10 2016
parent Jacob Carlborg <doob me.com> writes:
On 2016-07-10 19:09, Robert burner Schadek wrote:

 Yes if anybody had access to the trello and would want to use yet
 another tool. I think that is unrealistic.
Trello is already used: https://trello.com/dlang -- /Jacob Carlborg
Jul 10 2016
prev sibling parent tsbockman <thomas.bockman gmail.com> writes:
On Friday, 8 July 2016 at 18:04:16 UTC, Andrei Alexandrescu wrote:
 "Oops, can't let checkedint happen but I can't criticize 
 without proposing an alternative so forget RCStr and let me 
 work on that"
 ...
 On 07/08/2016 05:17 AM, Robert burner Schadek wrote:
 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.
My bid for inclusion of `checkedint` in Phobos fizzled because I want to solve a different (though overlapping) set of problems than you do. No matter how much I iterate and improve my work you still won't be satisfied, because our goals are incompatible and I'm not interested in discarding mine in favor of yours. This is clear from the response you gave when I explained in some detail the reasons for my design: https://forum.dlang.org/post/njss1a$2ig5$1 digitalmars.com
 Even if it were the case that there's no smaller design that 
 conforms with the requirements, that means requirements have a 
 problem.
You neither gave any *specific* suggestions as to how I could better meet my requirements, not did you state which of my numbered requirements, *specifically* was unreasonable or unnecessary. All of the major suggestions that you did give revolved around adding new requirements (like support for arbitrary bound ranges and user-defined error handling), while somehow shrinking the code base. Something had to give. Repeatedly dismissing this obvious goals mismatch as "insufficient quality" on my part is abrasive and unhelpful. Communicating clear requirements for projects ahead of time via pre-approval could help ensure that people who volunteer are actually working on something you want. Obviously I'm not the volunteer you're looking for, but maybe if we'd all known that I wouldn't have taken ownership of the project, and someone else would already have made what you want, instead.
Jul 19 2016
prev sibling next sibling parent reply "H. S. Teoh via Digitalmars-d-announce" writes:
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. T -- Nearly all men can stand adversity, but if you want to test a man's character, give him power. -- Abraham Lincoln
Jul 07 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jul 08 2016
parent reply Jack Stouffer <jack jackstouffer.com> writes:
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.
Jul 08 2016
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jul 08 2016
prev sibling next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 08/07/2016 7:55 AM, Andrei Alexandrescu wrote:
 https://wiki.dlang.org/Vision/2016H2 -- Andrei
We really need opRef* implemented in dmd.
Jul 07 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jul 08 2016
parent rikki cattermole <rikki cattermole.co.nz> writes:
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 :)
Jul 08 2016
prev sibling next sibling parent reply Johannes Pfau <nospam example.com> writes:
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
Jul 07 2016
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jul 08 2016
prev sibling next sibling parent reply =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com> writes:
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
Jul 08 2016
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jul 08 2016
parent =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com> writes:
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
Jul 09 2016
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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?
Jul 08 2016
parent =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com> writes:
On 2016-07-08 20:46:21 +0000, Walter Bright said:

 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
 ...
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.
I totally agree. But often it takes quite some time & experience to understand how the open deficiencies impact my context. I have seen to many tools where you can reach 80% and than things get hard / impossible. IMO a good or bad products is decided on the last 20%...
 3. How about a "D Master" online certificate? scrum.org is doing that. You have
 ...
It's a great idea, do you want to work on it?
I would love to but it's unrealistic within the next 6 months... sorry. I brought it up as an idea that can be put on the mid / long term roadmap, to shape the picture of D in the long run. I think these things are important for companies to see / know about before they will make a decision. It's a long, very long journey to establish a language in the "mainstream"... -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Jul 09 2016
prev sibling next sibling parent reply Eugene <egordeev18 gmail.com> writes:
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
Jul 08 2016
next sibling parent jmh530 <john.michael.hall gmail.com> writes:
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;
Jul 08 2016
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jul 08 2016
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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
Jul 08 2016
prev sibling next sibling parent reply Andrew Godfrey <X y.com> writes:
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.
Jul 08 2016
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jul 08 2016
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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_An rei.27s_Action_List within https://wiki.dlang.org/Vision/2016H2. Andrei
Jul 08 2016
prev sibling next sibling parent Karabuta <karabutaworld gmail.com> writes:
On Thursday, 7 July 2016 at 19:55:51 UTC, Andrei Alexandrescu 
wrote:
 https://wiki.dlang.org/Vision/2016H2 -- Andrei
Promote video tutorials? :)
Jul 08 2016
prev sibling next sibling parent reply Eugene <egordeev18 gmail.com> writes:
On Thursday, 7 July 2016 at 19:55:51 UTC, Andrei Alexandrescu 
wrote:
 https://wiki.dlang.org/Vision/2016H2 -- Andrei
is it possible to make a modular D language(and a compiler), so one just could release new features of the language without releasing a new version of a compiler(ldc, etc.), and these features would be just extensions of the compilers?
Jul 09 2016
parent Chris Wright <dhasenan gmail.com> writes:
On Sat, 09 Jul 2016 19:17:31 +0000, Eugene wrote:

 On Thursday, 7 July 2016 at 19:55:51 UTC, Andrei Alexandrescu wrote:
 https://wiki.dlang.org/Vision/2016H2 -- Andrei
is it possible to make a modular D language(and a compiler), so one just could release new features of the language without releasing a new version of a compiler(ldc, etc.), and these features would be just extensions of the compilers?
That would be kind of terrible by default. What ensures that two different modules are compatible? Nothing, by default. What happens if you try including two incompatible compiler modules in one project? Presumably an error. What if I try to depend on two libraries that have incompatible compiler modules? I can't. So it's a lot of work and would just fragment the language.
Jul 09 2016
prev sibling parent Javier <jfernand me.com> writes:
On Thursday, 7 July 2016 at 19:55:51 UTC, Andrei Alexandrescu 
wrote:
 https://wiki.dlang.org/Vision/2016H2 -- Andrei
Folks, One of the main obstacles I see to the adoption of a language is its ecosystem. Perhaps the vision should include a structure of frameworks we would like to see being developed, with a community process similar to what we follow for the language. vibe.d is already a tremendous asset, but we are lacking the equivalent of DBI, slf4j, JMS, etc. Does this sound like a good idea, and if so, does anybody want to help put something together like that? j.
Jul 14 2016