December 29, 2017
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.
December 29, 2017
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.
December 29, 2017
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.
December 29, 2017
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.
December 29, 2017
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.


December 30, 2017
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.

December 30, 2017
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.
December 30, 2017
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.
December 30, 2017
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.
December 30, 2017
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.