www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What do you want to see for a mature DLang?

reply IM <3di gm.com> writes:
I will start:

    -- Better compiler errors, better compiler errors, better 
compiler errors.


I really wish that the compiler errors could receive some 
refinement. Mostly it feels like some error text just being 
thrown at me. It needs to be better formatted, more helpful, with 
suggestions about how to fix (if possible).

To illustrate my point:

- See the compile errors I've just encountered with DMD: 
https://cdn.pbrd.co/images/H0q609l.png

- Now compare that with an error produced by rustc:
https://cdn.pbrd.co/images/H0q6bLi.png


Simple things like these make a big difference. D Lang has been 
around for a long while now, and hence signs of its maturity has 
to show everywhere, especially in the compiler, as well as the 
package manager.
Dec 28 2017
next sibling parent Daniel Kozak <kozzi11 gmail.com> writes:
You should fill an issue on issues.dlang.org for this particular case.
Compile should give you some hint, that you should use lvalue instead of
rvalue.

On Fri, Dec 29, 2017 at 8:53 AM, IM via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

 I will start:

    -- Better compiler errors, better compiler errors, better compiler
 errors.


 I really wish that the compiler errors could receive some refinement.
 Mostly it feels like some error text just being thrown at me. It needs to
 be better formatted, more helpful, with suggestions about how to fix (if
 possible).

 To illustrate my point:

 - See the compile errors I've just encountered with DMD:
 https://cdn.pbrd.co/images/H0q609l.png

 - Now compare that with an error produced by rustc:
 https://cdn.pbrd.co/images/H0q6bLi.png


 Simple things like these make a big difference. D Lang has been around for
 a long while now, and hence signs of its maturity has to show everywhere,
 especially in the compiler, as well as the package manager.
Dec 29 2017
prev sibling next sibling parent codephantom <me noyb.com> writes:
On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:
 I will start:
I will add: // ---------- module test; import std.stdio; safe void main() { writeln("I'd like to see safe as being the default"); } // ------------
Dec 29 2017
prev sibling next sibling parent vit <vit vit.vit> writes:
On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:
 I will start:

    -- Better compiler errors, better compiler errors, better 
 compiler errors.


 I really wish that the compiler errors could receive some 
 refinement. Mostly it feels like some error text just being 
 thrown at me. It needs to be better formatted, more helpful, 
 with suggestions about how to fix (if possible).

 To illustrate my point:

 - See the compile errors I've just encountered with DMD: 
 https://cdn.pbrd.co/images/H0q609l.png

 - Now compare that with an error produced by rustc:
 https://cdn.pbrd.co/images/H0q6bLi.png


 Simple things like these make a big difference. D Lang has been 
 around for a long while now, and hence signs of its maturity 
 has to show everywhere, especially in the compiler, as well as 
 the package manager.
Similar problem is when some template with alias callback fail to instantiate because callback contains error. Example: void foo(){ string str = 1; /++ nice error message: Error: cannot implicitly convert expression `1` of type `int` to `string` +/ import std.algorithm; [1, 2, 3].each!((x){ string str = 1 ///same error }); /++ horrible error message without root cause: source\app.d(660,14): Error: template app.foo.each!((x) { string str = 1; } ).each cannot deduce function from argument types !()(int[]), candidates are: C:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm\iteration.d(899,10): app.foo.each!((x) { string str = 1; } ).each(Range)(Range r) if (!isForeachIterable!Range && (isRangeIterable!Range || __traits(compiles, typeof(r.front).length))) C:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm\iteration.d(934,10): app.foo.each!((x) { string str = 1; } ).each(Iterable)(auto ref Iterable r) if (isForeachIterable!Iterable || __traits(compiles, Parameters!(Parameters!(r.opApply)))) +/ }
Dec 29 2017
prev sibling next sibling parent reply JN <666total wp.pl> writes:
AFAIK Rust doesn't have templates, but generics. Generics usually 
have much cleaner error messages because they are mostly used for 
generic functions and classes, meanwhile templates can do that 
too but much, much more, but when they break, you get entire 
paragraphs of template errors.
Dec 29 2017
parent reply I Love Stuffing <ilovestuffing gmail.com> writes:
On Friday, 29 December 2017 at 09:46:05 UTC, JN wrote:
 AFAIK Rust doesn't have templates, but generics. Generics 
 usually have much cleaner error messages because they are 
 mostly used for generic functions and classes, meanwhile 
 templates can do that too but much, much more, but when they 
 break, you get entire paragraphs of template errors.
Templates are bad because they write code for you. And it's that code you don't write that could have errors. It's a double edge sword. Also, for a mature D, some damn collections. Queues, Stacks, Deques, etc...
Dec 29 2017
next sibling parent reply Elronnd <elronnd elronnd.net> writes:
On Friday, 29 December 2017 at 22:05:31 UTC, I Love Stuffing 
wrote:
 Also, for a mature D, some damn collections. Queues, Stacks, 
 Deques, etc...
std.container.dlist (https://dlang.org/phobos/std_container_dlist.html)?
Dec 29 2017
parent rumbu <rumbu rumbu.ro> writes:
On Saturday, 30 December 2017 at 07:30:39 UTC, Elronnd wrote:
 On Friday, 29 December 2017 at 22:05:31 UTC, I Love Stuffing 
 wrote:
 Also, for a mature D, some damn collections. Queues, Stacks, 
 Deques, etc...
std.container.dlist (https://dlang.org/phobos/std_container_dlist.html)?
The queue or stack usage is not obvious at all. One would expect something like stack.push, stack.pop or queue.enque, queue.deque and may be a peek(). Instead one will get 33 functions that can be used with a doubly-linked list.
Dec 29 2017
prev sibling parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Friday, 29 December 2017 at 22:05:31 UTC, I Love Stuffing 
wrote:
 On Friday, 29 December 2017 at 09:46:05 UTC, JN wrote:
 AFAIK Rust doesn't have templates, but generics. Generics 
 usually have much cleaner error messages because they are 
 mostly used for generic functions and classes, meanwhile 
 templates can do that too but much, much more, but when they 
 break, you get entire paragraphs of template errors.
Templates are bad because they write code for you. And it's that code you don't write that could have errors. It's a double edge sword. Also, for a mature D, some damn collections. Queues, Stacks, Deques, etc...
Yes, it's the same issue in C when using complicated macros. You have to do all substitutions by hand to understand the real error message. D templates have more information so there's hope to get a better resolution of the error cause. But, the error message thing is a double edge sword, the more information is given the more difficult it gets to quickly find what the issue is. Again to illustrate with my C experience (sorry I'm paid for programming C, D is hobby that I try to sneakily introduce). The gcc 4 error messages were simple 1 lines errors, from gcc 5 on they introduced the multi-line errors with positioning like in that Rust example above. At the beginning I was quite happy with that as the error messages are so much more detailed, but now after some time, I find them really annoying as it is much more eye straining to find the real error message in between the positioning text.
Dec 30 2017
prev sibling next sibling parent Dylan Graham <dylan.graham2000 gmail.com> writes:
On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:
 I will start:

    -- Better compiler errors, better compiler errors, better 
 compiler errors.


 I really wish that the compiler errors could receive some 
 refinement. Mostly it feels like some error text just being 
 thrown at me. It needs to be better formatted, more helpful, 
 with suggestions about how to fix (if possible).

 To illustrate my point:

 - See the compile errors I've just encountered with DMD: 
 https://cdn.pbrd.co/images/H0q609l.png

 - Now compare that with an error produced by rustc:
 https://cdn.pbrd.co/images/H0q6bLi.png


 Simple things like these make a big difference. D Lang has been 
 around for a long while now, and hence signs of its maturity 
 has to show everywhere, especially in the compiler, as well as 
 the package manager.
I'd like to see proper DLL (shared library) support and DIP45 implemented. I'm making a project that I hope in the future will be extendable with D plugins.
Dec 29 2017
prev sibling next sibling parent reply angel <andrey.gelman gmail.com> writes:
Built-in tuples:

{val1, val2} = func();


On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:
 I will start:

    -- Better compiler errors, better compiler errors, better 
 compiler errors.


 I really wish that the compiler errors could receive some 
 refinement. Mostly it feels like some error text just being 
 thrown at me. It needs to be better formatted, more helpful, 
 with suggestions about how to fix (if possible).

 To illustrate my point:

 - See the compile errors I've just encountered with DMD: 
 https://cdn.pbrd.co/images/H0q609l.png

 - Now compare that with an error produced by rustc:
 https://cdn.pbrd.co/images/H0q6bLi.png


 Simple things like these make a big difference. D Lang has been 
 around for a long while now, and hence signs of its maturity 
 has to show everywhere, especially in the compiler, as well as 
 the package manager.
Dec 29 2017
parent reply maarten van damme <maartenvd1994 gmail.com> writes:
I'd like to see proper DLL (shared library) support and DIP45 implemented.
I'm making a project that I hope in the future will be extendable with D plugins. Out of curiousity, what's wrong with the current dll support? 2017-12-29 11:36 GMT+01:00 angel via Digitalmars-d < digitalmars-d puremagic.com>:
 Built-in tuples:

 {val1, val2} = func();


 On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:

 I will start:

    -- Better compiler errors, better compiler errors, better compiler
 errors.


 I really wish that the compiler errors could receive some refinement.
 Mostly it feels like some error text just being thrown at me. It needs to
 be better formatted, more helpful, with suggestions about how to fix (if
 possible).

 To illustrate my point:

 - See the compile errors I've just encountered with DMD:
 https://cdn.pbrd.co/images/H0q609l.png

 - Now compare that with an error produced by rustc:
 https://cdn.pbrd.co/images/H0q6bLi.png


 Simple things like these make a big difference. D Lang has been around
 for a long while now, and hence signs of its maturity has to show
 everywhere, especially in the compiler, as well as the package manager.
Dec 29 2017
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 29/12/2017 11:03 AM, maarten van damme wrote:
  >I'd like to see proper DLL (shared library) support and DIP45 
 implemented. I'm making a project that I hope in the future will be 
 extendable with D plugins.
 
 
 Out of curiousity, what's wrong with the current dll support?
The starting problem is TypeInfo doesn't cross the dll/host binary boundary. Meaning no classes/exceptions.
Dec 29 2017
prev sibling next sibling parent Basile B. <b2.temp gmx.com> writes:
On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:
 I will start:
 [...]
 Simple things like these make a big difference. D Lang has been 
 around for a long while now, and hence signs of its maturity 
 has to show everywhere, especially in the compiler, as well as 
 the package manager.
I casually encountered D issues that i qualified as "major" but with the time passing i don't really care anymore. D has probably reached the point where improving quality has become harder and harder. Improving the quality does not scale linearly and i'd say so what you qualify as "Simple things like these" are harder to accomplish than that you think. the devil is in the details.
Dec 29 2017
prev sibling next sibling parent Satoshi <satoshi rikarin.org> writes:
On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:
 I will start:

    -- Better compiler errors, better compiler errors, better 
 compiler errors.


 I really wish that the compiler errors could receive some 
 refinement. Mostly it feels like some error text just being 
 thrown at me. It needs to be better formatted, more helpful, 
 with suggestions about how to fix (if possible).

 To illustrate my point:

 - See the compile errors I've just encountered with DMD: 
 https://cdn.pbrd.co/images/H0q609l.png

 - Now compare that with an error produced by rustc:
 https://cdn.pbrd.co/images/H0q6bLi.png


 Simple things like these make a big difference. D Lang has been 
 around for a long while now, and hence signs of its maturity 
 has to show everywhere, especially in the compiler, as well as 
 the package manager.
This topic was there for so many times. Tuples, async/await, maybe monad (eg. int?), conditional dereferencing qualifier?.identifier, coalescence operator return x ?? 42; better properties, default safety, explicit throw funcs, runtime reflection, ARC instead of GC, so support, ... The community is quite conservative about implementing new stuff in D. Look at for more info: http://forum.dlang.org/thread/sapqaonpjseeykdczmvw forum.dlang.org?page=1 http://forum.dlang.org/thread/ot1q8b$23pt$1 digitalmars.com?page=1 BTW: I decided to make my own language rather than forcing the community to implement something what I would like to see in the lang. https://github.com/Rikarin/Rin
Dec 29 2017
prev sibling next sibling parent Arek <arychlinski gmail.com> writes:
On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:
 I will start:
cut...
 Simple things like these make a big difference. D Lang has been 
 around for a long while now, and hence signs of its maturity 
 has to show everywhere, especially in the compiler, as well as 
 the package manager.
I would like to have a complete and well-defined memory model. And its proper implementation in the compiler.
Dec 29 2017
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:
    -- Better compiler errors, better compiler errors, better 
 compiler errors.
This is the only thing I greatly care about anymore. Biggest problem D has in real world use.
Dec 29 2017
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/29/2017 9:29 AM, Adam D. Ruppe wrote:
 On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:
    -- Better compiler errors, better compiler errors, better compiler errors.
This is the only thing I greatly care about anymore. Biggest problem D has in real world use.
This is not actionable. What is actionable is filing bugzilla enhancement requests with specific examples.
Dec 29 2017
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 29 December 2017 at 21:30:35 UTC, Walter Bright wrote:
 This is not actionable. What is actionable is filing bugzilla 
 enhancement requests with specific examples.
I've done better than that: I've written pull requests. https://github.com/dlang/dmd/pull/6806 There's also existing bugzilla entries such as https://issues.dlang.org/show_bug.cgi?id=7841 These things come up almost every day in user support requests (learn forum, irc, or stack overflow). You want my advice for what to fix on D? Just follow those places and focus on stuff people ask for help on.
Dec 29 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/29/2017 2:31 PM, Adam D. Ruppe wrote:
 On Friday, 29 December 2017 at 21:30:35 UTC, Walter Bright wrote:
 This is not actionable. What is actionable is filing bugzilla enhancement 
 requests with specific examples.
I've done better than that: I've written pull requests. https://github.com/dlang/dmd/pull/6806
Thank you!
 There's also existing bugzilla entries such as 
 https://issues.dlang.org/show_bug.cgi?id=7841
That's been closed for a while now.
 These things come up almost every day in user support requests (learn forum, 
 irc, or stack overflow). You want my advice for what to fix on D? Just follow 
 those places and focus on stuff people ask for help on.
As a matter of pragmatism and time management, I give priority to helping people who have expended the effort to document a problem and post it on bugzilla. There's enough there to fill all the time of many people.
Dec 29 2017
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 29 December 2017 at 23:24:45 UTC, Walter Bright wrote:
 That's been closed for a while now.
Well, take your pick: https://issues.dlang.org/show_bug.cgi?id=12694 https://issues.dlang.org/show_bug.cgi?id=13340 https://issues.dlang.org/show_bug.cgi?id=16059 You always tell people to post to bugzilla, but many of these things have been posted over and over again. Bugzilla search is terrible, so it is frequently hard to find, but there are many examples there. The benefit though of watching support requests is you see what people actually deal with day-to-day, and error messages, especially multiple overload matches of functions and templates and no template matches ones come up all the time. ALL THE TIME. From new users and experienced users alike. Most won't put it in bugzilla though: they just see it as their own personal failure instead of a technical problem we can fix. But any repeated support request should be seen as a user experience problem that we try to fix. This is where we'd get the most productivity - taking little bumps out of the road. D has no roadblocks; we can get a lot of stuff done with it exactly the way it is, but if you watch users actually try to use it, you'll see the road isn't as smooth as it could and should be.
Dec 29 2017
next sibling parent reply IM <3di gm.com> writes:
On Saturday, 30 December 2017 at 01:40:39 UTC, Adam D. Ruppe 
wrote:
 On Friday, 29 December 2017 at 23:24:45 UTC, Walter Bright 
 wrote:
 That's been closed for a while now.
Well, take your pick: https://issues.dlang.org/show_bug.cgi?id=12694 https://issues.dlang.org/show_bug.cgi?id=13340 https://issues.dlang.org/show_bug.cgi?id=16059 You always tell people to post to bugzilla, but many of these things have been posted over and over again. Bugzilla search is terrible, so it is frequently hard to find, but there are many examples there. The benefit though of watching support requests is you see what people actually deal with day-to-day, and error messages, especially multiple overload matches of functions and templates and no template matches ones come up all the time. ALL THE TIME. From new users and experienced users alike. Most won't put it in bugzilla though: they just see it as their own personal failure instead of a technical problem we can fix. But any repeated support request should be seen as a user experience problem that we try to fix. This is where we'd get the most productivity - taking little bumps out of the road. D has no roadblocks; we can get a lot of stuff done with it exactly the way it is, but if you watch users actually try to use it, you'll see the road isn't as smooth as it could and should be.
Just curious, why Bugzilla and not something else? I can guess the following: - A centralized place for all dmd, druntime, and phobos was needed. - GitHub issues are probably more limited in features and functionality than Bugzilla. But think about it. Filing a bug on Bugzilla is not friction-free. One has to create an account, if s/he has one already, good luck remembering the username and password for something you rarely use, so spend sometime trying to remember and when you fail, spend time resetting your account or creating a new one. Finally file a bug and pray that someone will actually notice it and triage it to the appropriate owner! Not to mention that Bugzilla's UI is not pleasant. For GitHub issues, most probably you already have an account there that you use often. Issues are close to where the code is. It's easy to see potential owners from the code's blame or git log. .. etc. For better community participation, friction needs to be minimized as much as possible.
Dec 29 2017
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 30 December 2017 at 02:37:24 UTC, IM wrote:
 Just curious, why Bugzilla and not something else?
Bugzilla was the most well-known solution at the time. Keep in mind the D bugzilla has been around since 2006. As far as I understand it, migration at this point is deemed a big pain.
Dec 29 2017
parent reply Seb <seb wilzba.ch> writes:
On Saturday, 30 December 2017 at 02:50:48 UTC, Adam D. Ruppe 
wrote:
 On Saturday, 30 December 2017 at 02:37:24 UTC, IM wrote:
 Just curious, why Bugzilla and not something else?
Bugzilla was the most well-known solution at the time. Keep in mind the D bugzilla has been around since 2006. As far as I understand it, migration at this point is deemed a big pain.
No it wouldn't be a big pain. There are many tools for automatically migrating issues from Bugzilla. The only thing depending on Bugzilla is the changelog generator, but it's API calls to Bugzilla can be replaced with GitHub API calls within an hour. So the entire migration could be easily done in a lot less than a day. The only reason we still use Bugzilla is that the core people are used to it. Here are a couple of the common arguments: 1) Bugzilla is our, we don't want to depend on GitHub The D ecosystem already heavily depends on GitHub. Exporting the issues from GitHub would be easy. Besides there is only one person with access to the Bugzilla server. 2) GitHub only has per registry issues Bugzilla uses components too, they don't support global issues either. Besides if that's required one could easily create a meta repository for such global tasks. 3) Bugzilla's issue tracker is more sophisticated Sure, but does this help when you loose out on many contributors? GitHub even has build tools and sites that let anyone discover "easy" issues if they are labeled accordingly. It's free marketing. FYI I asked the same question 1 1/2 years ago: https://forum.dlang.org/post/ezldcjzpmsnxvvncncsi forum.dlang.org Since then, for example, GitHub got voting for issues, but Bugzilla lost it.
Dec 31 2017
next sibling parent reply Meta <jared771 gmail.com> writes:
On Sunday, 31 December 2017 at 11:18:26 UTC, Seb wrote:
 On Saturday, 30 December 2017 at 02:50:48 UTC, Adam D. Ruppe 
 wrote:
 Bugzilla was the most well-known solution at the time. Keep in 
 mind the D bugzilla has been around since 2006. As far as I 
 understand it, migration at this point is deemed a big pain.
No it wouldn't be a big pain. There are many tools for automatically migrating issues from Bugzilla. The only thing depending on Bugzilla is the changelog generator, but it's API calls to Bugzilla can be replaced with GitHub API calls within an hour. So the entire migration could be easily done in a lot less than a day. The only reason we still use Bugzilla is that the core people are used to it. Here are a couple of the common arguments: 1) Bugzilla is our, we don't want to depend on GitHub The D ecosystem already heavily depends on GitHub. Exporting the issues from GitHub would be easy. Besides there is only one person with access to the Bugzilla server. 2) GitHub only has per registry issues Bugzilla uses components too, they don't support global issues either. Besides if that's required one could easily create a meta repository for such global tasks. 3) Bugzilla's issue tracker is more sophisticated Sure, but does this help when you loose out on many contributors? GitHub even has build tools and sites that let anyone discover "easy" issues if they are labeled accordingly. It's free marketing. FYI I asked the same question 1 1/2 years ago: https://forum.dlang.org/post/ezldcjzpmsnxvvncncsi forum.dlang.org Since then, for example, GitHub got voting for issues, but Bugzilla lost it.
I wholeheartedly agree. The customer is always right, especially when you're trying to get them to donate their time to an open source project. It's more essential than ever that we lower barriers to participation; if Github issues is the hip new thing all the kids like, then we need to switch to that. We shouldn't be constantly switching to the shiniest new toy, but nor should we stubbornly stick to a piece of software that was built (and it looks it) in '90s. Or at least we should if we're trying to attract the kind of people for whom not using Github is a deal breaker. Older C++/Java programmers likely don't care, but younger Python/Ruby/JS users will.
Dec 31 2017
parent reply Mengu <mengukagan gmail.com> writes:
On Sunday, 31 December 2017 at 19:49:07 UTC, Meta wrote:
 On Sunday, 31 December 2017 at 11:18:26 UTC, Seb wrote:
 On Saturday, 30 December 2017 at 02:50:48 UTC, Adam D. Ruppe 
 wrote:
 Bugzilla was the most well-known solution at the time. Keep 
 in mind the D bugzilla has been around since 2006. As far as 
 I understand it, migration at this point is deemed a big pain.
No it wouldn't be a big pain. There are many tools for automatically migrating issues from Bugzilla. The only thing depending on Bugzilla is the changelog generator, but it's API calls to Bugzilla can be replaced with GitHub API calls within an hour. So the entire migration could be easily done in a lot less than a day. The only reason we still use Bugzilla is that the core people are used to it. Here are a couple of the common arguments: 1) Bugzilla is our, we don't want to depend on GitHub The D ecosystem already heavily depends on GitHub. Exporting the issues from GitHub would be easy. Besides there is only one person with access to the Bugzilla server. 2) GitHub only has per registry issues Bugzilla uses components too, they don't support global issues either. Besides if that's required one could easily create a meta repository for such global tasks. 3) Bugzilla's issue tracker is more sophisticated Sure, but does this help when you loose out on many contributors? GitHub even has build tools and sites that let anyone discover "easy" issues if they are labeled accordingly. It's free marketing. FYI I asked the same question 1 1/2 years ago: https://forum.dlang.org/post/ezldcjzpmsnxvvncncsi forum.dlang.org Since then, for example, GitHub got voting for issues, but Bugzilla lost it.
I wholeheartedly agree. The customer is always right, especially when you're trying to get them to donate their time to an open source project. It's more essential than ever that we lower barriers to participation; if Github issues is the hip new thing all the kids like, then we need to switch to that. We shouldn't be constantly switching to the shiniest new toy, but nor should we stubbornly stick to a piece of software that was built (and it looks it) in '90s. Or at least we should if we're trying to attract the kind of people for whom not using Github is a deal breaker. Older C++/Java programmers likely don't care, but younger Python/Ruby/JS users will.
there are three things that i've noticed: - in this thread, there is not a single positive post by walter. none. nada. zilch. it'd have been much better if he just did not post anything. - d leadership is dusty and so are their tools. we are no js community and hope we never become anything like them but bugzilla is a hundred years old. i am on github, i am on this ml and i also need a bugzilla account? what else do i need to be a part of this community? why can't you provide me a seamless travel in between? have a forum software, allow me to sign in via github and i am a member of the community. but no, they love their ugly bugzilla, they love their mailing list. - has anyone realized we do not attract anyone who has just started to learn programming? what are we going to do about it?
Dec 31 2017
parent reply rjframe <dlang ryanjframe.com> writes:
On Sun, 31 Dec 2017 23:50:04 +0000, Mengu wrote:

 - d leadership is dusty and so are their tools. we are no js community
 and hope we never become anything like them but bugzilla is a hundred
 years old. i am on github, i am on this ml and i also need a bugzilla
 account?
That's probably not the best method of effecting change. With the exception of the "Add me to CC list" interface (which is inexcusable) I like Bugzilla. It might be possible to clean things up a bit to better utilize it, but it offers more flexibility than Github's simple issue tracker does (there's a reason Atlassian is able to sell Jira to Bitbucket users even with a tracker integrated into Bitbucket). Druntime and Phobos are so closely integrated that being able to search for issues on both of them at once can be helpful; I would sometimes require two separate searches if they were on Github.
Dec 31
parent reply Pjotr Prins <pjotr.public12 thebird.nl> writes:
On Monday, 1 January 2018 at 02:02:03 UTC, rjframe wrote:
 That's probably not the best method of effecting change.
It killed off the discussion nicely, indeed. I am just going to share my thoughts a little. Github, in my opinion, is hype and even though I depend on it today, I am trying to decrease that dependency. We should build a world that is not dependent on single companies. I am not downplaying what github has done for us (I am one of the early users) - but they have just become a little too important for free software to be comfortable. The github issue tracker is wanting anyway. D is a great language. I just spent 6 months in C++ and the last month worked on a D multi-threaded project again. I'll blog about this soon, but the short of it is that I am very grateful to Walter, Andrei, Kai, Ian, Johan and others for creating a language that fits our needs so well! D software is doing critical work around the world every second. D is probably not a language for the hype community - let them have Go and Rust. I honestly don't care. And D should not care. Great programmers gyrate to powerful languages and toolboxes. I love I can read the source code of Phobos and understand it. I love I get low level access to stack variables. I love I can manipulate the heap in any way I want. I love we can target GPU and KNL. I love we have Maybe even though it is called Nullable... A great programmer can handle D fine. As it is. Let's not try to be the next hype. Let's keep writing great software. Pj.
Jan 01
parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Monday, 1 January 2018 at 18:32:37 UTC, Pjotr Prins wrote:
 On Monday, 1 January 2018 at 02:02:03 UTC, rjframe wrote:
 That's probably not the best method of effecting change.
It killed off the discussion nicely, indeed. I am just going to share my thoughts a little. Github, in my opinion, is hype and even though I depend on it today, I am trying to decrease that dependency. We should build a world that is not dependent on single companies. I am not downplaying what github has done for us (I am one of the early users) - but they have just become a little too important for free software to be comfortable. The github issue tracker is wanting anyway. D is a great language. I just spent 6 months in C++ and the last month worked on a D multi-threaded project again. I'll blog about this soon, but the short of it is that I am very grateful to Walter, Andrei, Kai, Ian, Johan and others for creating a language that fits our needs so well! D software is doing critical work around the world every second. D is probably not a language for the hype community - let them have Go and Rust. I honestly don't care. And D should not care. Great programmers gyrate to powerful languages and toolboxes. I love I can read the source code of Phobos and understand it. I love I get low level access to stack variables. I love I can manipulate the heap in any way I want. I love we can target GPU and KNL. I love we have Maybe even though it is called Nullable... A great programmer can handle D fine. As it is. Let's not try to be the next hype. Let's keep writing great software.
+10000
Jan 02
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Jan 02, 2018 at 09:57:08AM +0000, Patrick Schluter via Digitalmars-d
wrote:
 On Monday, 1 January 2018 at 18:32:37 UTC, Pjotr Prins wrote:
[...]
 I am just going to share my thoughts a little. Github, in my
 opinion, is hype and even though I depend on it today, I am trying
 to decrease that dependency. We should build a world that is not
 dependent on single companies. I am not downplaying what github has
 done for us (I am one of the early users) - but they have just
 become a little too important for free software to be comfortable.
 The github issue tracker is wanting anyway.
 
 D is a great language. I just spent 6 months in C++ and the last
 month worked on a D multi-threaded project again. I'll blog about
 this soon, but the short of it is that I am very grateful to Walter,
 Andrei, Kai, Ian, Johan and others for creating a language that fits
 our needs so well! D software is doing critical work around the
 world every second. D is probably not a language for the hype
 community - let them have Go and Rust. I honestly don't care. And D
 should not care. Great programmers gyrate to powerful languages and
 toolboxes. I love I can read the source code of Phobos and
 understand it. I love I get low level access to stack variables. I
 love I can manipulate the heap in any way I want. I love we can
 target GPU and KNL. I love we have Maybe even though it is called
 Nullable...
 
 A great programmer can handle D fine. As it is. Let's not try to be
 the next hype. Let's keep writing great software.
 
+10000
+10000 * 2 T -- It is not the employer who pays the wages. Employers only handle the money. It is the customer who pays the wages. -- Henry Ford
Jan 02
parent reply IM <3di gm.com> writes:
On Tuesday, 2 January 2018 at 16:32:50 UTC, H. S. Teoh wrote:
 On Tue, Jan 02, 2018 at 09:57:08AM +0000, Patrick Schluter via 
 Digitalmars-d wrote:
 On Monday, 1 January 2018 at 18:32:37 UTC, Pjotr Prins wrote:
[...]
 I am just going to share my thoughts a little. Github, in my 
 opinion, is hype and even though I depend on it today, I am 
 trying to decrease that dependency. We should build a world 
 that is not dependent on single companies. I am not 
 downplaying what github has done for us (I am one of the 
 early users) - but they have just become a little too 
 important for free software to be comfortable. The github 
 issue tracker is wanting anyway.
 
 D is a great language. I just spent 6 months in C++ and the 
 last month worked on a D multi-threaded project again. I'll 
 blog about this soon, but the short of it is that I am very 
 grateful to Walter, Andrei, Kai, Ian, Johan and others for 
 creating a language that fits our needs so well! D software 
 is doing critical work around the world every second. D is 
 probably not a language for the hype community - let them 
 have Go and Rust. I honestly don't care. And D should not 
 care. Great programmers gyrate to powerful languages and 
 toolboxes. I love I can read the source code of Phobos and 
 understand it. I love I get low level access to stack 
 variables. I love I can manipulate the heap in any way I 
 want. I love we can target GPU and KNL. I love we have Maybe 
 even though it is called Nullable...
 
 A great programmer can handle D fine. As it is. Let's not 
 try to be the next hype. Let's keep writing great software.
 
+10000
+10000 * 2 T
To clarify, I too like D. It is certainly very pleasant to work with. This post wasn't about GitHub issues vs Bugzilla. That was a get-off-at-a-tangent topic. This post is about what's needed for a more mature D; mature enough for extremely big companies to build bigger and more critical parts of their tech stacks in D (this *is* a huge investment)! The goal is never about making D a hype language. I agree, a great programmer can handle anything, not just D as it is, but that's never an excuse to be complacent, it's never an excuse not aim for a higher quality in the D compiler and the infrastructure. Hope you understand. Thanks.
Jan 03
parent reply codephantom <me noyb.com> writes:
On Thursday, 4 January 2018 at 05:28:40 UTC, IM wrote:
 To clarify, I too like D. It is certainly very pleasant to work 
 with. This post wasn't about GitHub issues vs Bugzilla. That 
 was a get-off-at-a-tangent topic. This post is about what's 
 needed for a more mature D; mature enough for extremely big 
 companies to build bigger and more critical parts of their tech 
 stacks in D (this *is* a huge investment)! The goal is never 
 about making D a hype language.

 I agree, a great programmer can handle anything, not just D as 
 it is, but that's never an excuse to be complacent, it's never 
 an excuse not aim for a higher quality in the D compiler and 
 the infrastructure. Hope you understand.

 Thanks.
D is one of the most interesting and easy to use languages I've seen in a very long time, and I really enjoy 'playing' with it. However...what D needs, IMHO, is a strategy to better handle defects - as opposed to wishfully hoping that something will arise out of the chaos of bugzilla. This is not my area of experise, but, if I were a manager evaluating the merits of D for use in a corporate software project, and then I went off to bugzilla and looked at the items for D.. I'd pause and think.....wtf is going on here. I don't know how other open source projects manage this, or how other mainstream languages manage this, but I would assume there are 'best practices' out there...somewhere. I doubt very much whether just allowing stuff to pile up in some bugzilla repository, is a best practice.
Jan 03
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 4 January 2018 at 06:16:45 UTC, codephantom wrote:

 I doubt very much whether just allowing stuff to pile up in 
 some bugzilla repository, is a best practice.
Several bugs get wiped in each release, as the changelogs clearly show. It's not as if they're being ignored. If you know how to get a bunch of volunteers with such varied interests to work in a concerted direction, please do tell. And I'm not being facetious here. There have been attempts in the past to bring some sort of order to the chaos so that the perception matches the reality, but it's not something that has yet proven sustainable. As a result, bugs that no one steps up to fix get left in bugzilla for ages. I have an idea I'm working on to potentially help get older bugs squashed and older PRs merged. I need to hash out the details before getting it going, but I'll blog about when (and if) it comes to fruition. There are no guarantees it will be effective, but it's worth a shot. In the meantime, you could help reduce the pile by picking a bug to fix today. Multiple people, particularly those concerned about the number of old issues still open, who donate one or two days a month to fixing old bugs could go along way. The same goes for reviewing PRs.
Jan 03
next sibling parent codephantom <me noyb.com> writes:
On Thursday, 4 January 2018 at 06:39:24 UTC, Mike Parker wrote:
 If you know how to get a bunch of volunteers with such varied 
 interests to work in a concerted direction, please do tell.
This is the mystery behind everything in the universe. Why haven't you solved it yet?
Jan 03
prev sibling next sibling parent codephantom <me noyb.com> writes:
On Thursday, 4 January 2018 at 06:39:24 UTC, Mike Parker wrote:
 I have an idea I'm working on to potentially help get older 
 bugs squashed and older PRs merged. I need to hash out the 
 details before getting it going, but I'll blog about when (and 
 if) it comes to fruition. There are no guarantees it will be 
 effective, but it's worth a shot.
I think this might also be a good project for one of Andrei's students ;-) i.e a detailed analysis of D's bugzilla repository. Present the findings and recommendations.
 In the meantime, you could help reduce the pile by picking a 
 bug to fix today. Multiple people, particularly those concerned 
 about the number of old issues still open, who donate one or 
 two days a month to fixing old bugs could go along way. The 
 same goes for reviewing PRs.
I'm too much of 'big picture' person to get into such details ;-) Fortunately, not all are like me ;-) The problem, I suspect, is more to do with people wanting to contribute to things that matter most, and, that their contribution will be considered in a timely manner, by people with suitable expertise. If such a process exists, I am not aware of it. I don't think just saying to people, 'go and find some bug that interests you' is sufficient to get people motivated, IMHO.
Jan 03
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Jan 04, 2018 at 06:39:24AM +0000, Mike Parker via Digitalmars-d wrote:
[...]
 In the meantime, you could help reduce the pile by picking a bug to fix
 today. Multiple people, particularly those concerned about the number of old
 issues still open, who donate one or two days a month to fixing old bugs
 could go along way. The same goes for reviewing PRs.
[...] Back when I had more free time, I used to trawl bugzilla for low-numbered bugs to find low-hanging fruit to fix. It's not hard to setup various prebaked custom queries that allow me to, for example, find all bugs 1 month / 2 months / 1 year / 2-5 years old with just one mouse click. Bugzilla is actually highly configurable and can be made to do quite useful things, as long as people get past the fallacious preconception that no eye candy == lousy. Over time, at least while I was active, I have noticed that the number of trivial bugs has shrunk significantly, and most of the lingering old issues are the ones that are actually very difficult to fix. So the talk about stuff rotting in bugzilla and forgotten is mostly unfounded speculation of people who haven't even bothered to look deeper than the superficial appeatance, rather than a reflection of reality. Nowadays I've less time to trawl through bugzilla but every now and then an issue comes up that can be fixed in the few spare minutes that I have, and I still try to contribute when I can. And I've noticed that the number of bugs fixed per release seems to have increased, so progress *is* being made in this area. What's lacking right now is more people to direct more energy to fixing bugs and reviewing PRs rather than wasting that energy complaining in the forums. For the sheer amount of energy spent arguing on the forum, so many more bugs could have been fixed, and so many more PRs reviewed. We don't even require you to have commit access in order to be able to give useful feedback to a PR. I don't know how much lower the barrier can get. Heck, *I* got commit access because I was actively submitting and reviewing Phobos PRs as a non-committer. It all comes down to who's doing the actual work vs. who's just telling others what they think they should be doing, which rarely, if ever, works. T -- Don't get stuck in a closet---wear yourself out.
Jan 03
next sibling parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Thursday, 4 January 2018 at 07:47:41 UTC, H. S. Teoh wrote:
 [...]
I'm missing Kenji...
Jan 04
prev sibling parent codephantom <me noyb.com> writes:
On Thursday, 4 January 2018 at 07:47:41 UTC, H. S. Teoh wrote:
 It all comes down to who's doing the actual work vs. who's just 
 telling others what they think they should be doing, which 
 rarely, if ever, works.
I think that view really needs to be challenged. Those who might be willing to contribute are probably not sitting around waiting for someone to tell them what to do. On the other hand, there may be legitmate reasons why they are not just getting involved and doing things. I suspect, and I could be wrong, that a lack of clear process could be a matter of concern. I also suspect, and I could be wrong, that working out where best to exert their effort is not as simple as just finding something that interest them. I also expect, that not everyone using D, or using these forums, need to be, or are equipped to be, contributors to resolving D's bugs. Such people should still feel free to express their concerns, without being told that they should go and do something. Software quality is more important than ever, as it can impact us in dramatic ways these days. D needs to have quality assurance process in place to ensure that D's repository of bugs are appropriately being assessed, categorised, prioritised, and actioned - and this needs to evident to all. Then and only then, wil willing contributors be better positioned to make decisions about where to exert their effort. I see this a problem for the D Foundation to address, and not something left up to the randomness of the open source development model. btw. (although I don't see this as 'the' solution)... I do like this idea of labeling stuff more clearly.. http://issuehub.io/label-guide
Jan 04
prev sibling parent reply rjframe <dlang ryanjframe.com> writes:
On Thu, 04 Jan 2018 06:16:45 +0000, codephantom wrote:

 This is not my area of experise, but, if I were a manager evaluating the
 merits of D for use in a corporate software project, and then I went off
 to bugzilla and looked at the items for D.. I'd pause and think.....wtf
 is going on here.
 
 I don't know how other open source projects manage this, or how other
 mainstream languages manage this, but I would assume there are 'best
 practices' out there...somewhere.
 
 I doubt very much whether just allowing stuff to pile up in some
 bugzilla repository, is a best practice.
At the time of writing: Ansible has 3391 open bugs[1] (and ~master is often used in production). Python has more than 6000, 2000+ with patches[2]. GCC (C and C++ components only) has 3119[3]. Bugs are part of software. That's just life. It doesn't mean the software is unreliable/unusable, just that it can be better. [1]: https://github.com/ansible/ansible/issues [2]: https://bugs.python.org/issue? template=stats [3]: https://gcc.gnu.org/bugzilla/report.cgi? x_axis_field=&y_axis_field=bug_status&z_axis_field=&no_redirect=1&query_format=report- table&short_desc_type=allwordssubstr&short_desc=&product=gcc&component=c&component=c %2B% 2B&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&cf_known_to_fail_type=allwords&cf_known_to_work_type=allwords&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&cf_gcchost_type=allwordssubstr&cf_gcchost=&cf_gcctarget_type=allwordssubstr&cf_gcctarget=&cf_gccbuild_type=allwordssubstr&cf_gccbuild=&bug_id=&bug_id_type=anyexact&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&emailtype3=substring&email3=&chfieldvalue=&chfieldfrom=&chfieldto=Now&j_top=AND&f1=noop&o1=noop&v1=&format=table&action=wrap
Jan 04
next sibling parent codephantom <me noyb.com> writes:
On Thursday, 4 January 2018 at 12:11:36 UTC, rjframe wrote:
 At the time of writing:

 Ansible has 3391 open bugs[1] (and ~master is often used in 
 production).
 Python has more than 6000, 2000+ with patches[2].
 GCC (C and C++ components only) has 3119[3].

 Bugs are part of software. That's just life. It doesn't mean 
 the software is unreliable/unusable, just that it can be better.
Whether D is usable, reliable or whatever was not my argument. My argument is more broader, and is about how an opensource project, like D for example, looks out for the interests of its users. i.e quality assurance. 1000's of bugs suggest to me, a lack of QA. A lack of QA suggests to me, a lack of concern for the interests of users. There are numerous research papers in this area, some of which I am in the process of reading, to gain a better understanding of QA in open source projects - and apparently it's a real issue of concern to those researching this topic. Anyway, as I go through these research papers, I suspect that it is unlikely they will conclude that bugs are just a part of software, and that's just life.. and least.. I hope not.
Jan 04
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 4 January 2018 at 12:11:36 UTC, rjframe wrote:
 Python has more than 6000, 2000+ with patches[2].
Most appears to be library related or improvement requests… I don't think numbers is the right metric. Tools with as many users as Python will get a lot of issues reported irrespective of severity or frequency.
Jan 05
prev sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Sunday, December 31, 2017 11:18:26 Seb via Digitalmars-d wrote:
 On Saturday, 30 December 2017 at 02:50:48 UTC, Adam D. Ruppe

 wrote:
 On Saturday, 30 December 2017 at 02:37:24 UTC, IM wrote:
 Just curious, why Bugzilla and not something else?
Bugzilla was the most well-known solution at the time. Keep in mind the D bugzilla has been around since 2006. As far as I understand it, migration at this point is deemed a big pain.
No it wouldn't be a big pain. There are many tools for automatically migrating issues from Bugzilla. The only thing depending on Bugzilla is the changelog generator, but it's API calls to Bugzilla can be replaced with GitHub API calls within an hour. So the entire migration could be easily done in a lot less than a day. The only reason we still use Bugzilla is that the core people are used to it. Here are a couple of the common arguments:
I honestly am unaware of any reason why using github issues would be superior to bugzilla except that some folks expect projects on github to use github issues for bug reports. And plenty of projects on github don't use github issues. If we were starting from scratch, then maybe it would make sense to use github issues instead of our own bugzilla, but given that we already have bugzilla, it works just fine, and github issues really don't seem to offer anything significant that would make them superior to using bugzilla, I really don't see any reason to switch.
 1) Bugzilla is our, we don't want to depend on GitHub

 The D ecosystem already heavily depends on GitHub. Exporting the
 issues from GitHub would be easy. Besides there is only one
 person with access to the Bugzilla server.
Yes, it would be a pain to switch away from github at this point, but if github went down permanently tomorrow, it would just be an annoying roadblock. We almost certainly wouldn't lose any code (at most, a few commits, if no one pulled recently enough), and we wouldn't lose any bug reports. We'd have to go to the trouble of setting up our own gitlab or switching to bitbucket or something like that and pointing all of the automated stuff to the new place, and it would be a royal pain, but we wouldn't lose any information. If all of the issues were on github, and github went away, we'd lose them. Sure, github is unlikely to go away, but I see no reason to tie ourselves to it thoroughly enough that we're going to lose data if they go away - especially since I don't actually see any benefit in switching to github issues.
 2) GitHub only has per registry issues

 Bugzilla uses components too, they don't support global issues
 either. Besides if that's required one could easily create a meta
 repository for such global tasks.
Well, it wouldn't be the end of the world if the issues were separated by repos, but having them in a single place where they can be searched together is beneficial, and it makes it easier to switch an issue between components when it turns out that it was assigned to the wrong component. Certainly, switching to github would be negative in this regard, even if it wouldn't be a deal breaker.
 3) Bugzilla's issue tracker is more sophisticated

 Sure, but does this help when you loose out on many contributors?
 GitHub even has build tools and sites that let anyone discover
 "easy" issues if they are labeled accordingly. It's free
 marketing.
I seriously doubt that we've lost many (if any) contributors because we don't use github issues, and plenty of other projects use github without using it as their issue tracker.
 FYI I asked the same question 1 1/2 years ago:
 https://forum.dlang.org/post/ezldcjzpmsnxvvncncsi forum.dlang.org

 Since then, for example, GitHub got voting for issues, but
 Bugzilla lost it.
To be honest, no one seems to pay attention to voting on issues. Having a voting system is theoretically beneficial, but in practice, it doesn't seem to have generally had much effect on what gets fixed (not for us anyway). Almost inevitably, the stuff that actually gets many votes is the hard stuff that is likely to be sitting around whether folks vote on it or not. Plenty of those issues really should be fixed sooner, but having a lot of votes on them isn't what does it. e.g. issue #314 sat around for ages in spite of everyone agreeing that it needed to be fixed, because it a was a hard problem, and no one stepped up to the plate to take care of it. The fact that it had a bunch of votes really didn't matter. In any case, I have yet to see much on argument for why we would even want to switch to github issues. It just seems like some folks think that for some reason, the fact that we have our code up on github means that we should have our issue tracker there too and that it's weird that we don't. Personally, I don't see any reason to go to the trouble of searching and invalidating years worth of links just because using github issues seems to be the hip thing to do. It needs to provide serious value over using our own bugzilla, and I am unaware of anything that it does that is significantly better than using bugzilla. - Jonathan M Davis
Dec 31
parent rjframe <dlang ryanjframe.com> writes:
On Sun, 31 Dec 2017 17:19:22 -0700, Jonathan M Davis wrote:

 Yes, it would be a pain to switch away from github at this point, but if
 github went down permanently tomorrow, it would just be an annoying
 roadblock. We almost certainly wouldn't lose any code (at most, a few
 commits, if no one pulled recently enough), and we wouldn't lose any bug
 reports. We'd have to go to the trouble of setting up our own gitlab or
 switching to bitbucket or something like that and pointing all of the
 automated stuff to the new place, and it would be a royal pain, but we
 wouldn't lose any information. If all of the issues were on github, and
 github went away, we'd lose them.
 
 Sure, github is unlikely to go away, but I see no reason to tie
 ourselves to it thoroughly enough that we're going to lose data if they
 go away - especially since I don't actually see any benefit in switching
 to github issues.
If only one person has access to Bugzilla, we're actually at a greater risk now than if we used Github for issues. If we don't have regular backups to a location accessible to multiple members of the core team, we shouldn't consider Bugzilla to be a reliable data repository. --Ryan
Dec 31
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Creating a bugzilla account takes a couple minutes. It is enough friction to 
serve as a reasonable filter against spammers and junk postings.

It's not like we have a shortage of bugzilla issues and are wondering what to
do 
next.

It's working well enough for those who care enough to make an effort.
Dec 29 2017
parent reply Muld <2 2.2> writes:
On Saturday, 30 December 2017 at 06:55:13 UTC, Walter Bright 
wrote:
 It's not like we have a shortage of bugzilla issues and are 
 wondering what to do next.
Yah there are a ton of Bugzilla issues, that's the problem. More than half of them aren't "actionable" as you put it. Here's the problem, look at something like Rust: Pull requests? 95 open, it's about the same as Dlang, But if you go to the last page... https://github.com/rust-lang/rust/pulls?page=4&q=is%3Apr+is%3Aopen Look at that the oldest one is from October 15th, 20_17_. Now we go to DMD... https://github.com/dlang/dmd/pulls?page=6&q=is%3Apr+is%3Aopen Oldest one is from January 17, 20_13_. In contrast this same problem exists for Bugzilla. You say it's working cause it's better than using notepad or some other stupid shit. Bugzilla isn't the issue, it's the fact the people maintaining it aren't willing to commit to anything and leave issues open that shouldn't be left open. That just results in noise making it difficult to see what actual issues are. I'm not even talking about duplicate entries as you seem to have have misunderstood.
Dec 30 2017
next sibling parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On 30 December 2017 at 15:42, Muld via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Saturday, 30 December 2017 at 06:55:13 UTC, Walter Bright wrote:
 It's not like we have a shortage of bugzilla issues and are wondering what
 to do next.
Yah there are a ton of Bugzilla issues, that's the problem. More than half of them aren't "actionable" as you put it.
There's nothing unmanageable about the issue tracker, nor are the number of open bugs even a reliable measure of anything. For instance, Python has more than twice as many open bugs than D.
 Here's the problem, look at something like Rust:

 Pull requests? 95 open, it's about the same as Dlang, But if you go to the
 last page...

 https://github.com/rust-lang/rust/pulls?page=4&q=is%3Apr+is%3Aopen

 Look at that the oldest one is from October 15th, 20_17_.

 Now we go to DMD...

 https://github.com/dlang/dmd/pulls?page=6&q=is%3Apr+is%3Aopen

 Oldest one is from January 17, 20_13_.
Hey, I take offence to that. https://issues.dlang.org/show_bug.cgi?id=17839 https://github.com/dlang/dmd/pull/7503 https://github.com/dlang/dmd/pull/7508 https://github.com/dlang/dmd/pull/7509 https://github.com/dlang/dmd/pull/7510 https://github.com/dlang/dmd/pull/7527 https://github.com/dlang/dmd/pull/7536 And many more closed that were even older, and I'm not the only one reviving these patches, all of which are either abandoned, incomplete, or too controversial (there is always a valid reason why open PRs were left to rot).
 In contrast this same problem exists for Bugzilla. You say it's working
 cause it's better than using notepad or some other stupid shit. Bugzilla
 isn't the issue, it's the fact the people maintaining it aren't willing to
 commit to anything and leave issues open that shouldn't be left open. That
 just results in noise making it difficult to see what actual issues are. I'm
 not even talking about duplicate entries as you seem to have have
 misunderstood.
All open issues are actionable, and require some action. They are not noise, and many issues whose fix requires a change in language specification or semantics are understandably left to the few who have the authoritative to make such final decisions on whether it should be accepted or rejected. Age of issue is not a big deal. In fact I see it as a good sign that at least issues are left to breathe while we wait and understand the impact or urgency of it. As opposed to jumping in and fixing issues immediately without taking due diligence on the wider picture it affects.
Dec 30 2017
next sibling parent reply codephantom <me noyb.com> writes:
On Saturday, 30 December 2017 at 16:36:57 UTC, Iain Buclaw wrote:
 All open issues are actionable, and require some action.  They 
 are not noise, and many issues whose fix requires a change in 
 language specification or semantics are understandably left to 
 the few who have the authoritative to make such final decisions 
 on whether it should be accepted or rejected.

 Age of issue is not a big deal.  In fact I see it as a good 
 sign that at least issues are left to breathe while we wait and 
 understand the impact or urgency of it.  As opposed to jumping 
 in and fixing issues immediately without taking due diligence 
 on the wider picture it affects.
Is this a problem with triage? i.e. like a hositpital emergency ward chaos rules, cause nobody is on duty triaging. How does a contributor prioritise their contribution to items in bugzilla? Or is it perhaps a tooling problem? (i.e. bugzilla lacks features that are needed). Or is it a problem with not having enough people on duty, triaging? Or is it a problem with just too many patients coming in? Or .. ??
Dec 30 2017
parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On 31 December 2017 at 02:07, codephantom via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Saturday, 30 December 2017 at 16:36:57 UTC, Iain Buclaw wrote:
 All open issues are actionable, and require some action.  They are not
 noise, and many issues whose fix requires a change in language specification
 or semantics are understandably left to the few who have the authoritative
 to make such final decisions on whether it should be accepted or rejected.

 Age of issue is not a big deal.  In fact I see it as a good sign that at
 least issues are left to breathe while we wait and understand the impact or
 urgency of it.  As opposed to jumping in and fixing issues immediately
 without taking due diligence on the wider picture it affects.
Is this a problem with triage? i.e. like a hositpital emergency ward chaos rules, cause nobody is on duty triaging. How does a contributor prioritise their contribution to items in bugzilla?
Either: 1. By picking up an issue that you have a vested interest in seeing fixed. 2. Feel free to look at the list of regressons. https://issues.dlang.org/buglist.cgi?bug_severity=regression&component=dmd&list_id=218477&query_format=advanced&resolution=--- Bigger projects or features are delegated between the core maintainers, or if a champion comes to take the reigns, then they have the freedom to go ahead. For everything else, it is pretty much a free-for-all in terms of what you want to get fixed. Almost nobody is being paid to contribute to the language here.
Dec 30 2017
parent codephantom <me noyb.com> writes:
On Sunday, 31 December 2017 at 02:06:03 UTC, Iain Buclaw wrote:
 2. Feel free to look at the list of regressons.
     
 https://issues.dlang.org/buglist.cgi?bug_severity=regression&component=dmd&list_id=218477&query_format=advanced&resolution=---
"This list is too long for Bugzilla's little mind" Mmm..just imagine how our human mind reacts then ;-) But... as you point out...some 'filtering' makes it 'seem' a little less daunting ;-)
Dec 30 2017
prev sibling parent Muld <2 2.2> writes:
On Saturday, 30 December 2017 at 16:36:57 UTC, Iain Buclaw wrote:
 Hey, I take offence to that.

 https://issues.dlang.org/show_bug.cgi?id=17839

 https://github.com/dlang/dmd/pull/7503 
 https://github.com/dlang/dmd/pull/7508 
 https://github.com/dlang/dmd/pull/7509 
 https://github.com/dlang/dmd/pull/7510 
 https://github.com/dlang/dmd/pull/7527 
 https://github.com/dlang/dmd/pull/7536

 And many more closed that were even older, and I'm not the only 
 one reviving these patches, all of which are either abandoned, 
 incomplete, or too controversial (there is always a valid 
 reason why open PRs were left to rot).
I haven't been looking recently. At least there's one vigilante working in the shadows, doing the things no one else is willing to.
Dec 31 2017
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/30/2017 6:42 AM, Muld wrote:
 In contrast this same problem exists for Bugzilla. You say it's working cause 
 it's better than using notepad or some other stupid shit. Bugzilla isn't the 
 issue, it's the fact the people maintaining it aren't willing to commit to 
 anything and leave issues open that shouldn't be left open. That just results
in 
 noise making it difficult to see what actual issues are. I'm not even talking 
 about duplicate entries as you seem to have have misunderstood.
Anyone can contribute to bugzilla with reasoned advice about what to do with various issues, and can review PRs. The people responsible are, well, anyone who wants to be. Please join and help out.
Dec 30 2017
parent reply IM <3di gm.com> writes:
On Sunday, 31 December 2017 at 05:43:57 UTC, Walter Bright wrote:
 On 12/30/2017 6:42 AM, Muld wrote:
 In contrast this same problem exists for Bugzilla. You say 
 it's working cause it's better than using notepad or some 
 other stupid shit. Bugzilla isn't the issue, it's the fact the 
 people maintaining it aren't willing to commit to anything and 
 leave issues open that shouldn't be left open. That just 
 results in noise making it difficult to see what actual issues 
 are. I'm not even talking about duplicate entries as you seem 
 to have have misunderstood.
Anyone can contribute to bugzilla with reasoned advice about what to do with various issues, and can review PRs. The people responsible are, well, anyone who wants to be. Please join and help out.
While we are discussing it here, could you please let me know what the bug triage process for each release cycle is? Is it random that anyone picks up whatever bug s/he feels like fixing? Or is it that if contributors will contribute X number of patches this cycle, then there is some sort of guidance and direction of this effort towards fixing some high priority bugs?
Dec 30 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/30/2017 11:23 PM, IM wrote:
 While we are discussing it here, could you please let me know what the bug 
 triage process for each release cycle is? Is it random that anyone picks up 
 whatever bug s/he feels like fixing? Or is it that if contributors will 
 contribute X number of patches this cycle, then there is some sort of guidance 
 and direction of this effort towards fixing some high priority bugs?
Bugs are ranked by severity, but generally what gets fixed are bugs that a particular person self-selects an interest in fixing it. Often people who just want to help out will peruse the buglist looking for issues that match their skill levels that they can fix.
Dec 30 2017
next sibling parent reply IM <3di gm.com> writes:
On Sunday, 31 December 2017 at 07:43:35 UTC, Walter Bright wrote:
 On 12/30/2017 11:23 PM, IM wrote:
 While we are discussing it here, could you please let me know 
 what the bug triage process for each release cycle is? Is it 
 random that anyone picks up whatever bug s/he feels like 
 fixing? Or is it that if contributors will contribute X number 
 of patches this cycle, then there is some sort of guidance and 
 direction of this effort towards fixing some high priority 
 bugs?
Bugs are ranked by severity, but generally what gets fixed are bugs that a particular person self-selects an interest in fixing it. Often people who just want to help out will peruse the buglist looking for issues that match their skill levels that they can fix.
I hope that you could see that this doesn't scale very well, and some kind of a process needs to be established to shape and direct the efforts. Some thoughts/suggestions: - Weekly meeting to review open bugs, adjust their components and priority appropriately, and assign to potential owners (those who can or likely to fix the bugs. Owners can then reassign or unassign if not interested). - Maybe ask someone to volunteer for triaging bugs in each component. So every component has an owner. - If a bug has been assigned to someone and hasn't received any attention (i.e. remained open for say 3 months), a bot should unassign it so that it returns back to the triage pool, hoping that it will catch the attention of the triage volunteers. What do you think? Do you agree that a process is needed?
Dec 31 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/31/2017 8:18 AM, IM wrote:
 What do you think? Do you agree that a process is needed?
We've tried adding process before. It does not work, for the simple reason that it requires a dedicated group of people to dedicate time to it. Are you willing to do that? We have added process when someone has stepped up to do the thankless job of administering it.
Dec 31 2017
next sibling parent codephantom <me noyb.com> writes:
On Sunday, 31 December 2017 at 21:16:35 UTC, Walter Bright wrote:
 On 12/31/2017 8:18 AM, IM wrote:
 What do you think? Do you agree that a process is needed?
We've tried adding process before. It does not work, for the simple reason that it requires a dedicated group of people to dedicate time to it. Are you willing to do that? We have added process when someone has stepped up to do the thankless job of administering it.
Well, I've spent the last few months just learning the language, debating issues on this forum, and fending off the occasional attack. This is probably what most newcomers will go through too.. For the most part, I think D is a really nice language to 'play' with, and thanks to all those that have made it happen. Now as I think about moving from just playing with D, to making serious use of it, this lack of 'process' you mention, could become a real deal breaker. The D Foundation should take this matter very seriously, in my opinion, and invest in process, rather than just hoping it will emerge out of the chaos of bugzilla. By not focusing your attention on this more, I believe you risk a lot of people refusing to contribute to D, and even turning away from D. You also risk fragmentation in the D community. Now, that asisde, happy New Year to you, and all. Lets' make it a great year to advance D even further...
Dec 31
prev sibling parent IM <3di gm.com> writes:
On Sunday, 31 December 2017 at 21:16:35 UTC, Walter Bright wrote:
 On 12/31/2017 8:18 AM, IM wrote:
 What do you think? Do you agree that a process is needed?
We've tried adding process before. It does not work, for the simple reason that it requires a dedicated group of people to dedicate time to it.
Something should work. It just needs to be found. People are already dedicating time to D by contributing fixes and filing issues, responding on the forums, ... etc. Organizing work and priorities is not an exception. It doesn't take that long by the way, only 30 ~ 60 minutes per week max should be more than enough. I hope you could take the upcoming DConf as an opportunity to discuss with others ways to enhance the process and minimize friction.
 Are you willing to do that?
I'd be happy to do it, but I'm not the right person for it. This needs someone who knows D very well, knows the bigger picture, and is familiar with the contributors and who mostly works on what to be able to adjust priorities and ownership appropriately. I've been learning and experimenting with D only for a few months. Also, I'm worried about - though unlikely - to put myself in a conflict-of-interest situation; we don't use D at work, and as far as I know there are neither interest nor plans to do so. I hope this will change one day, and that's why I started this post, because quality and maturity are very important.
 We have added process when someone has stepped up to do the 
 thankless job of administering it.
I think it is thankful and as important as submitting PRs and DIPs. Shaping, organizing, and directing human effort are just as important as the human effort itself.
Jan 01
prev sibling parent reply Muld <2 2.2> writes:
On Sunday, 31 December 2017 at 05:43:57 UTC, Walter Bright wrote:
 Please join and help out.
I already have, and like I said there are problems with with the current system. I don't feel like helping anymore cause anything time I do my work just get dumped, and I've simply wasted my time.
 Bugs are ranked by severity, but generally what gets fixed are 
 bugs that a particular person self-selects an interest in 
 fixing it.

 Often people who just want to help out will peruse the buglist 
 looking for issues that match their skill levels that they can 
 fix.
You've just admitted to the problem. And those that want to "help out" will "persue the buglist looking for issues". Then you drop this quote, "it's fine for those that want to put in a wasteful time of effort, cause they care enough".
 It's working well enough for those who care enough to make an 
 effort.
Fix your shit if you want help, it's broken and just wastes people's time. Saying that people don't care enough is not helping with a solution.
Dec 31 2017
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/31/2017 12:53 PM, Muld wrote:
 Fix your shit
A word to the wise. Being rude will just get you ignored by most everyone on this n.g. We insist on professional demeanor and courtesy at all times. Egregious behavior will get posts unceremoniously removed.
Dec 31 2017
prev sibling parent Binghoo Dang <dangbinghoo gmail.com> writes:
On Sunday, 31 December 2017 at 20:53:37 UTC, Muld wrote:
 ...
Stop making noise except one-day you make another well-known language popular in the world called E. What a kind of people who you are ? and can make such a noise to well known and famous person who made such a great language? And, everyone who's making noise just stop. If you don't like D, just go to Go or Rust. The community is just kindly making opensource project which means they are contributing times and life to the human. and what you do except making noise? And Dear Walter is working for D all the time, Didn't anyone seen he is merging PRs on github? So, let's be calm and graceful, that is if you consider there's problem, just fix it. Or provides more detailed information for the core team to fix it. Not just saying "D is bad on this or that". And at least, keep polite if you're not a guy like Bill Gates or Jobs.
Jan 05
prev sibling parent reply Meta <jared771 gmail.com> writes:
On Saturday, 30 December 2017 at 14:42:45 UTC, Muld wrote:
 On Saturday, 30 December 2017 at 06:55:13 UTC, Walter Bright 
 wrote:
 It's not like we have a shortage of bugzilla issues and are 
 wondering what to do next.
Yah there are a ton of Bugzilla issues, that's the problem. More than half of them aren't "actionable" as you put it. Here's the problem, look at something like Rust: Pull requests? 95 open, it's about the same as Dlang, But if you go to the last page... https://github.com/rust-lang/rust/pulls?page=4&q=is%3Apr+is%3Aopen Look at that the oldest one is from October 15th, 20_17_. Now we go to DMD... https://github.com/dlang/dmd/pulls?page=6&q=is%3Apr+is%3Aopen Oldest one is from January 17, 20_13_.
This is a problem that many of us are working on fixing. The main reason many of these old zombie PRs stick around is that historically, people are hesitant to close things (for a variety of social reasons, I feel). While there is still the slightest chance that something might someday be merged, it is kept open. Rust is a lot more aggressive about closing bad or outdated PRs and either guiding PRs that need work to get to a mergeable state, or closing them and communicating that this is not the correct way to go. I watched a talk by a Rust contributor specifically on this point awhile ago - they have a bot that does a lot of the PR closure work to get around the fact that people are hesitant to be the "bad guy" and tell someone that their work is not good enough. D needs to get much better at this, and I think things are happening - slowly. The bad optics and demoralizing effect of letting things sit forever without definitive action outweighs the potential loss from being more aggressive about closing or merging.
Dec 31 2017
parent reply Seb <seb wilzba.ch> writes:
On Sunday, 31 December 2017 at 09:37:35 UTC, Meta wrote:
 On Saturday, 30 December 2017 at 14:42:45 UTC, Muld wrote:
 On Saturday, 30 December 2017 at 06:55:13 UTC, Walter Bright 
 wrote:
 It's not like we have a shortage of bugzilla issues and are 
 wondering what to do next.
Yah there are a ton of Bugzilla issues, that's the problem. More than half of them aren't "actionable" as you put it. Here's the problem, look at something like Rust: Pull requests? 95 open, it's about the same as Dlang, But if you go to the last page... https://github.com/rust-lang/rust/pulls?page=4&q=is%3Apr+is%3Aopen Look at that the oldest one is from October 15th, 20_17_. Now we go to DMD... https://github.com/dlang/dmd/pulls?page=6&q=is%3Apr+is%3Aopen Oldest one is from January 17, 20_13_.
This is a problem that many of us are working on fixing. The main reason many of these old zombie PRs stick around is that historically, people are hesitant to close things (for a variety of social reasons, I feel). While there is still the slightest chance that something might someday be merged, it is kept open. Rust is a lot more aggressive about closing bad or outdated PRs and either guiding PRs that need work to get to a mergeable state, or closing them and communicating that this is not the correct way to go. I watched a talk by a Rust contributor specifically on this point awhile ago - they have a bot that does a lot of the PR closure work to get around the fact that people are hesitant to be the "bad guy" and tell someone that their work is not good enough. D needs to get much better at this, and I think things are happening - slowly. The bad optics and demoralizing effect of letting things sit forever without definitive action outweighs the potential loss from being more aggressive about closing or merging.
Yes, Dlang-bot was able to detect stalled issues for a while, but we didn't turn this on for all repositories. I have just enabled it: https://github.com/dlang-bots/dlang-bot/pull/153 For the moment, it is just labelling issues with e.g. "needs work", "needs rebase", "stalled", "stalled-stable". In a next stage it will start to actively ping people or close PRs. Also automatically rebasing PRs if there are no conflicts is on the radar (the GitHub UI is quite conservative in this regard).
Dec 31 2017
parent Meta <jared771 gmail.com> writes:
On Sunday, 31 December 2017 at 11:27:41 UTC, Seb wrote:
 Yes, Dlang-bot was able to detect stalled issues for a while, 
 but we didn't turn this on for all repositories. I have just 
 enabled it:

 https://github.com/dlang-bots/dlang-bot/pull/153

 For the moment, it is just labelling issues with e.g. "needs 
 work", "needs rebase", "stalled", "stalled-stable".
 In a next stage it will start to actively ping people or close 
 PRs.
 Also automatically rebasing PRs if there are no conflicts is on 
 the radar (the GitHub UI is quite conservative in this regard).
Awesome. Thanks for all your hard work on the automation side of things, by the way. It's not glamorous but it's a huge force multiplier.
Dec 31 2017
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/29/2017 5:40 PM, Adam D. Ruppe wrote:
 [...]
PRs to fix bugzilla issues get submitted every day. I don't see a better way. I can't monitor every forum, I rely on you and others to do so and submit the issues.
Dec 29 2017
prev sibling parent reply Muld <2 2.2> writes:
On Friday, 29 December 2017 at 21:30:35 UTC, Walter Bright wrote:
 On 12/29/2017 9:29 AM, Adam D. Ruppe wrote:
 On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:
    -- Better compiler errors, better compiler errors, better 
 compiler errors.
This is the only thing I greatly care about anymore. Biggest problem D has in real world use.
This is not actionable. What is actionable is filing bugzilla enhancement requests with specific examples.
Bugzilla is a huge mess tbh, creating a request in bugzilla won't lead anywhere. There's so many pointless entries in there people have to waste their time looking through just to see what is and isn't "actionable" (as you put it). I was thinking of making a senseless entry that had some fake example code and see how long it would take for the entry to be closed/removed. Something tells me it would never be closed/removed. The barrier for what constitutes a bugzilla entry and why it can remain open should be stricter. For example anything that is an "enhancement" and would require a DIP should not remain open. Bugzilla shouldn't be a "wishlist" for Dlang. This just adds needless bloat, what's worse is when an enchantment is not labelled that it needs a DIP and someone goes wasting their time implementing it. It's so bad honestly it'd probably be less work just to create a new bugzilla and port any relevant entries from the current one.
Dec 29 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/29/2017 3:15 PM, Muld wrote:
 Bugzilla is a huge mess tbh, creating a request in bugzilla won't lead
anywhere.
Fixes for bugzilla issues are posted on github nearly every day.
 It's so bad honestly it'd probably be less work just to create a new bugzilla 
 and port any relevant entries from the current one.
It's not a big deal to create a duplicate of existing entries. As to bugzilla itself, despite its issues, it is far far far better and more organized than randomly looking in chat rooms, stack overflow, newsgroups, etc.
Dec 29 2017
parent Muld <2 2.2> writes:
On Friday, 29 December 2017 at 23:27:38 UTC, Walter Bright wrote:
 On 12/29/2017 3:15 PM, Muld wrote:
 Bugzilla is a huge mess tbh, creating a request in bugzilla 
 won't lead anywhere.
Fixes for bugzilla issues are posted on github nearly every day.
This does not mean anything, just cause fixes for Bugzilla issues are being fixed "nearly every day" is not part of the larger problem. The people that are pushing fixes for those issues tend to be the same people that are creating them. Sure I can create a bugzilla issue, but unless I'm the one that creates a fix for it, it probably won't be fixed unless it is a regression.
 It's so bad honestly it'd probably be less work just to create 
 a new bugzilla and port any relevant entries from the current 
 one.
It's not a big deal to create a duplicate of existing entries. As to bugzilla itself, despite its issues, it is far far far better and more organized than randomly looking in chat rooms, stack overflow, newsgroups, etc.
Living on Mars is far far better than trying to live on the surface of the Sun. Just cause that's the case doesn't mean you should stop looking for a place called Earth.
Dec 30 2017
prev sibling parent reply IM <3di gm.com> writes:
On Friday, 29 December 2017 at 17:29:47 UTC, Adam D. Ruppe wrote:
 On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:
    -- Better compiler errors, better compiler errors, better 
 compiler errors.
This is the only thing I greatly care about anymore. Biggest problem D has in real world use.
Please allow me to give an example of how first impressions of maturity really matter! Recently at some company, a group of engineers started advocating for using Rust. They wrote a doc explaining the differences and benefits of Rust over C++ (which is heavily used). People started experimenting, and immediately the maturity and good user experience of rustc and cargo were quite obvious. The result was that Rust is now more appealing, some new projects were written in Rust, some old ones have or are being migrated from C++ to Rust. (**This is a real story by the way**) Now, given the fact that I love D despite some of the annoying issues I encounter with it frequently, I would like to call my colleagues to give it a try and experiment with it. People start getting interested. They start writing some code, and eventually they hit one of those unhelpful compile error messages, which could indicate one of the following: - An error in the engineer's knowledge of the language which the compiler didn't help to understand what it is so that s/he goes to look it up. - A bug in Phobos. - An actual compiler bug or inconsistency. Remember, those engineers are experimenting with D to use it for serious projects at work, not personal toy projects. What do you think? Is it likely that they decide to invest a lot of time and resources migrating projects to D? Maturity (or at least approaching it as much as possible) is VERY VERY VERY important. I like what the D foundation did to the website, the language and library docs, the Learn section, the forums, the resources ... etc. That definitely gives the impression of maturity. Looking forward to seeing more of that in the compiler, which is the single most important thing in a programming language, the reason it exists, the thing I interface with most of the time.
Dec 29 2017
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/29/2017 7:07 PM, IM wrote:
 They start writing 
 some code, and eventually they hit one of those unhelpful compile error 
 messages, which could indicate one of the following:
 - An error in the engineer's knowledge of the language which the compiler
didn't 
 help to understand what it is so that s/he goes to look it up.
 - A bug in Phobos.
 - An actual compiler bug or inconsistency.
I'm sorry, there is literally nothing I can do with that. To get action, you need to be specific.
Dec 29 2017
prev sibling next sibling parent ag0aep6g <anonymous example.com> writes:
On 12/30/2017 04:07 AM, IM wrote:
 I like what the D foundation did to the website, the language and 
 library docs, the Learn section, the forums, the resources ... etc. That 
 definitely gives the impression of maturity.
As far as I'm aware, the foundation isn't too active in those areas; unless Vladimir or Seb are on their payroll now. Maybe the foundation pays the electricity bills, but the work is done by volunteers.
Dec 30 2017
prev sibling parent reply Laeeth Isharc <laeeth laeeth.com> writes:
On Saturday, 30 December 2017 at 03:07:57 UTC, IM wrote:
 On Friday, 29 December 2017 at 17:29:47 UTC, Adam D. Ruppe 
 wrote:
 On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:
    -- Better compiler errors, better compiler errors, better 
 compiler errors.
This is the only thing I greatly care about anymore. Biggest problem D has in real world use.
Please allow me to give an example of how first impressions of maturity really matter! Recently at some company, a group of engineers started advocating for using Rust. They wrote a doc explaining the differences and benefits of Rust over C++ (which is heavily used). People started experimenting, and immediately the maturity and good user experience of rustc and cargo were quite obvious. The result was that Rust is now more appealing, some new projects were written in Rust, some old ones have or are being migrated from C++ to Rust. (**This is a real story by the way**) Now, given the fact that I love D despite some of the annoying issues I encounter with it frequently, I would like to call my colleagues to give it a try and experiment with it. People start getting interested. They start writing some code, and eventually they hit one of those unhelpful compile error messages, which could indicate one of the following: - An error in the engineer's knowledge of the language which the compiler didn't help to understand what it is so that s/he goes to look it up. - A bug in Phobos. - An actual compiler bug or inconsistency. Remember, those engineers are experimenting with D to use it for serious projects at work, not personal toy projects. What do you think? Is it likely that they decide to invest a lot of time and resources migrating projects to D? Looking forward to seeing more of that in the compiler, which is the single most important thing in a programming language, the reason it exists, the thing I interface with most of the time.
 Remember, those engineers are experimenting with D to use it 
 for serious projects at work, not personal toy projects. What 
 do you think? Is it likely that they decide to invest a lot of 
 time and resources migrating projects to D?
Then probably you did the right thing in not suggesting they move to using D at work at the current time. There are all kinds of coordination costs in adopting D immediately for serious projects where the people involved don't know the language yet and where the benefits of D don't seem compelling at this point. It's much better if the people involved start using D on the side for things that aren't mission critical or that don't have a tight deadline, unless D solves a particular sort of problem you have or theres much receptivity to it. I don't think D is at a point where it should be sold. People need to be receptive and ready to move towards you. And they need to be able to take decisions on the basis of intrinsic merits and not have to consider social factors. They means that the natural sphere of adoption is startups run by creative and independent minded people, smaller firms and small groups within large firms where people have autonomy. That's really quite okay - in the US, more than 100% of new jobs are created by smaller firms. Its a mistake to use a language you don't know for a mission critical project with a tight deadline, unless it solves so many problems that it is worth the inevitable teething problems. Doing so is a recipe for brittleness because it's hard to anticipate any difficulties and hard to plan for them. D naturally is spread much thinner than many other languages because it's more ambitious and is useful for many different domains, so if you're in a particular one of them then you will know many fewer people using D then would be the case for languages that are more adapted for particular domains. Also, there's much difference in how much people in different areas tend to talk about what they are doing. Web guys talk a lot; finance guys not do much. The people I have met who use D at work mostly don't develop open source stuff at work and they don't post all that much in the forums. We are rewriting our core analytics used across the firm (about 95 people) to D. Why? Because they need to be accessible from other languages so C ABI is necessary and it's not even a contest, D vs C++. And the person in charge of that project is a Fellow in Maths at Cambridge, and the one helping him is also a Cambridge mathematician so they realise how important beauty is in taming complexity, and D does exceptionally well on that front. We can then programmatically generate wrappers for other languages and we can connect the analytics and some micro services with a little domain specific language written using pegged. So it's highly unusual sets of people like that, or like the founders of Sociomantic, or like the EMSI guys, or Liran's guys at Weka that are likely to be D adopters in the next wave. Not people who can't see through error messages (which are much better than C++ anyway).
 I like what the D foundation did to the website, the language 
 and library docs, the Learn section, the forums, the resources 
 ... etc. That definitely gives the impression of maturity.
I'm not sure those changes were primarily a consequence of things the D Foundation did, though maybe I'm wrong. You know how the runnable examples appeared? Seb Wilzbach, who appeared out of nowhere, decided to make them happen. Initially people didn't even see the point of them and there was some modest resistance.
 Maturity (or at least approaching it as much as possible) is 
 VERY VERY VERY important.
D is rough around the edges as an ecosystem. That's because the people involved care deeply about technical things and less so about making things incredibly comfortable for new users. Language ecosystems have difjferent values - when you pick a language you're marrying into that ecosystem, and whether it's right for you depends on the values you hold. The cost of that is obvious, but the benefit comes in other ways, including the capabilities of the set of people involved with D. That D isn't a shiny thing for now does act as a filter to discourage people who can't see through that. I don't think you can act mature when you aren't. In time D ecosystem will be mature and we will be reminiscing about those days when one could know the people involved and it was intrinsic rather than career motivation that attracted newcomers. For the time being that isn't the case, so one has to pick one's poison and decide what's important. Maybe for those who can't recognise what D offers at this point, D isn't the language for them and they should try Rust or Go. Maturity for the ecosystem will come.. In the meantime taking action or giving money is a much more effective way to shape things than saying "you know what you should do if you were a billionaire is this". It would be nice to have more resources - one could do things with them, but for the time being one is where one is, so suggesting that the Foundation should do X or Y isn't likely to have nearly as much impact as figuring out one tiny step towards it and becoming in part the change you wish to see. Maturity of the language is something else. The compilers seem quite usable - in 2014 I would regularly have segfaults and that's rare these days. The documentation has gone from being terrifying to non sophisticated programmers to my being able to say to colleagues we should have documentation as good as this,and runnable examples is good motivation to write unit tests too. I agree that better error messages would be nice. They're already a lot better, and I guess that will continue.
Jan 04
parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Friday, 5 January 2018 at 01:29:04 UTC, Laeeth Isharc wrote:

 So it's highly unusual sets of people like that, or like the 
 founders of Sociomantic, or like the EMSI guys, or Liran's guys 
 at Weka that are likely to be D adopters in the next wave. Not 
 people who can't see through error messages (which are much 
 better than C++ anyway).
+1000 I would add that D should leverage the fact that is a "company friendly" language: the core team cares about problems raised by commercials that are using it (or, at least, it try hard to do it! :-P). That's pretty unique, in that phase of his history, compared to what we can see around. Well, it should do this in a more structured way, as I've suggested to Andrei, but it's definitely a big plus. /Paolo
Jan 05
prev sibling next sibling parent Neia Neutuladh <neia ikeran.org> writes:
On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:
    -- Better compiler errors, better compiler errors, better 
 compiler errors.
Very much so. I actually made a list a day or two ago. Some of it is more speculative than concrete, though: * unicode categories to determine what can be an identifier (there's no reason not to support, say, Canadian aboriginal syllabaries; it would just be too much work to list out each range of glyphs) * concepts / compile-time interfaces (makes ranges easier to deal with and document) * safe by default * function parameters are const scope by default (I recall this was a major request when const was first introduced) * mixin templates (a template designed to be mixed in is likely not to work if simply invoked; this also gets us most of what people have been asking for with macros) * possibly, block syntax for functions and templates whose last parameter is a function or alias
Dec 29 2017
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/28/2017 11:53 PM, IM wrote:
 Simple things like these make a big difference. D Lang has been around for a 
 long while now, and hence signs of its maturity has to show everywhere, 
 especially in the compiler, as well as the package manager.
Diverging from the: file(line): message format is problematic because a lot of editors rely on that to position the editor on the offending line.
Dec 29 2017
next sibling parent reply Seb <seb wilzba.ch> writes:
On Friday, 29 December 2017 at 21:34:14 UTC, Walter Bright wrote:
 On 12/28/2017 11:53 PM, IM wrote:
 Simple things like these make a big difference. D Lang has 
 been around for a long while now, and hence signs of its 
 maturity has to show everywhere, especially in the compiler, 
 as well as the package manager.
Diverging from the: file(line): message format is problematic because a lot of editors rely on that to position the editor on the offending line.
It's easy to detect whether the compiler is invoked in a TTY. Even if this turns out to be tricky, showing more helpful information to the user with a special flag (e.g. `--explain` or `--detailed`) is a way to go forward.
Dec 29 2017
parent Atila Neves <atila.neves gmail.com> writes:
On Friday, 29 December 2017 at 21:56:26 UTC, Seb wrote:
 On Friday, 29 December 2017 at 21:34:14 UTC, Walter Bright 
 wrote:
 On 12/28/2017 11:53 PM, IM wrote:
 Simple things like these make a big difference. D Lang has 
 been around for a long while now, and hence signs of its 
 maturity has to show everywhere, especially in the compiler, 
 as well as the package manager.
Diverging from the: file(line): message format is problematic because a lot of editors rely on that to position the editor on the offending line.
It's easy to detect whether the compiler is invoked in a TTY. Even if this turns out to be tricky, showing more helpful information to the user with a special flag (e.g. `--explain` or `--detailed`) is a way to go forward.
Being in an editor does not imply being in a TTY. Atila
Dec 29 2017
prev sibling parent reply rjframe <dlang ryanjframe.com> writes:
On Fri, 29 Dec 2017 13:34:14 -0800, Walter Bright wrote:

 On 12/28/2017 11:53 PM, IM wrote:
 Simple things like these make a big difference. D Lang has been around
 for a long while now, and hence signs of its maturity has to show
 everywhere, especially in the compiler, as well as the package manager.
Diverging from the: file(line): message format is problematic because a lot of editors rely on that to position the editor on the offending line.
I think the idea of the OP is that the message should be better; not that it should have an identical format to the Rust error. file(line): better message isn't going to mess with anybody's tools. I noticed the Rust error has a code, too (E0308); if better error messages are too difficult to implement, assigning codes to error types and documenting them on the wiki could be helpful. Once you've dealt with an error type, the messages aren't that bad, but having documentation for the first time you run into it would be nice. Somewhat-related question out of curiosity: is there ever a time the error message "template instance foo!(bar) error instantiating" is actually needed? I've always seen it paired with a message that actually describes the problem, so is just noise.
Dec 29 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/29/2017 1:57 PM, rjframe wrote:
 I noticed the Rust error has a code, too (E0308); if better error messages
 are too difficult to implement, assigning codes to error types and
 documenting them on the wiki could be helpful. Once you've dealt with an
 error type, the messages aren't that bad, but having documentation for the
 first time you run into it would be nice.
Many compilers produce such error codes. I've considered it many times, but eventually concluded it added negative value. 1. Typing in an error code is so 1980's :-) People expect better these days. 2. A list of error messages with explanations can be trivially searched with a simple 'find text' command, which is much easier than typing in an error code. 3. Ideally there'd be a url one could click on, not an error code. 4. It's ugly.
 Somewhat-related question out of curiosity: is there ever a time the error
 message "template instance foo!(bar) error instantiating" is actually
 needed?
Yes. It shows where the error originates in the user's code.
Dec 29 2017
parent codephantom <me noyb.com> writes:
On Friday, 29 December 2017 at 23:32:45 UTC, Walter Bright wrote:
 ...
 3. Ideally there'd be a url one could click on, not an error 
 code.
 ....
No URLs! (unless they point to 'local' documentation). I do not want to become even more dependent on having access to the internet, in order to debug programs.
Dec 29 2017
prev sibling parent radagast <brucewayneshit gmail.com> writes:
On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote:
 I will start:

    -- Better compiler errors, better compiler errors, better 
 compiler errors.


 I really wish that the compiler errors could receive some 
 refinement. Mostly it feels like some error text just being 
 thrown at me. It needs to be better formatted, more helpful, 
 with suggestions about how to fix (if possible).

 To illustrate my point:

 - See the compile errors I've just encountered with DMD: 
 https://cdn.pbrd.co/images/H0q609l.png

 - Now compare that with an error produced by rustc:
 https://cdn.pbrd.co/images/H0q6bLi.png


 Simple things like these make a big difference. D Lang has been 
 around for a long while now, and hence signs of its maturity 
 has to show everywhere, especially in the compiler, as well as 
 the package manager.
* R-value references. * More "Hands free" package/dependency management (See Cargo(Rust)) * GC dependency free stdlib, with built-in general purpose async i/o library * More sophisticated, official language server * Better IDE support * Full-fledged smart pointer (resembling std::unique_ptr<T>, std::shared_ptr<T>, std::weak_ptr<T> in the standard * Riddance of `object`, and being able to hand-make rootobject. No common root class.
Dec 30 2017