On 3/22/2018 9:15 PM, Norm wrote:
> On Friday, 23 March 2018 at 03:28:05 UTC, Walter Bright wrote:
>> What are the bugzilla issues on those?
> 
> This is just a few cut-paste from the collated list. Some were reported but found later to be duplicates, many were existing bugs, so no new bugzilla was created in those cases.
> 
> https://issues.dlang.org/show_bug.cgi?id=18055
> https://issues.dlang.org/show_bug.cgi?id=17942
> https://issues.dlang.org/show_bug.cgi?id=16317
> https://issues.dlang.org/show_bug.cgi?id=16189
> https://issues.dlang.org/show_bug.cgi?id=17949
> https://issues.dlang.org/show_bug.cgi?id=15511
> https://issues.dlang.org/show_bug.cgi?id=16107

Thank you. I have tagged them with the "Industry" keyword, which is for issues raised by people using D in industrial situations. The last one (16107) is marked as resolved and appears to have been fixed.

On Friday, 23 March 2018 at 01:49:30 UTC, Nick Sabalausky (Abscissa) wrote:
> On 03/22/2018 09:44 PM, Jonathan M Davis wrote:
>> On Thursday, March 22, 2018 21:25:11 Nick Sabalausky  via Digitalmars-d
>> wrote:
>>> On 03/18/2018 11:43 PM, Norm wrote:
>>>> We don't want to be treated special. We don't want to give back. This is
>>>> the *entire* point.
>>>
>>> An attitude like that and there's any wonder it didn't work out? Sheesh.
>>>
>>> This is the thing about OSS: The business willing to give back (and
>>> there are many such businesses) are the ones that reap benefits. The
>>> companies that wilfully cling to zero-sum bullshit are on their own, by
>>> their own choice, and open themselves to allowing their competitors to
>>> take the advantage for themselves. That is the way of the world, that is
>>> the way of reality.
>>>
>>> D can't be held responsible for self-defeating zero-sum, "us vs them"
>>> mentalities. Sheesh.
>> 
>> While I do think that there's a lot to be said for companies who are willing
>> to use open source and give back to the community in the process, there are
>> plenty of people (and not just companies) who just want a tool to get things
>> done. And I don't think that there's anything wrong with that.
>
> I agree. The problem is with saying "I want X, and I'm not willing to offer anything for it." And then wondering why it doesn't work out.

I suppose it's about finding that balance between growing the D user base, and trying to get said user base to give back.

Say I was offered a car with no windscreen...I have 3 responses:
1. Cool! I'll put in a windscreen myself, as this car has a great engine.
2. Thanks. This car does a great job getting from a to b, pity about all these bugs flying in my face though. Wish I knew more about windscreens.
3. No thank you, I'll just stick with the train. Nice spinner rims, btw.

Regarding D, I fall into (2), but sometimes I wonder if catching the train would be easier...

On 03/23/2018 03:35 AM, Jordan Wilson wrote:
> 
> I suppose it's about finding that balance between growing the D user base, and trying to get said user base to give back.
> 
> Say I was offered a car with no windscreen...I have 3 responses:
> 1. Cool! I'll put in a windscreen myself, as this car has a great engine.
> 2. Thanks. This car does a great job getting from a to b, pity about all these bugs flying in my face though. Wish I knew more about windscreens.
> 3. No thank you, I'll just stick with the train. Nice spinner rims, btw.
> 
> Regarding D, I fall into (2), but sometimes I wonder if catching the train would be easier...

I used to be (2) with D, but that was something like ten years ago. At this point, it's more like a brand new sedan, well-built, reasonably priced, great mileage, a few minor things I've tweaked or done differently if I had a magic wand, but otherwise a car that leaves me wondering "Why are people whining about the lack of spinner support and iPhone whiz-bangery? Big effing deal."

That's NOT a comment on Manu's OP here, of course. Something like "Why is x^^y *still* not CTFE-able???" is the kind of thing I completely sympathize with. Can't imagine that sort of thing being a blocker though, especially if I were still doing a lot of work in C or C++.

On Friday, 23 March 2018 at 05:24:48 UTC, Walter Bright wrote:
> On 3/22/2018 9:15 PM, Norm wrote:
>> On Friday, 23 March 2018 at 03:28:05 UTC, Walter Bright wrote:
>>> What are the bugzilla issues on those?
>> 
>> This is just a few cut-paste from the collated list. Some were reported but found later to be duplicates, many were existing bugs, so no new bugzilla was created in those cases.
>> 
>> https://issues.dlang.org/show_bug.cgi?id=18055
>> https://issues.dlang.org/show_bug.cgi?id=17942
>> https://issues.dlang.org/show_bug.cgi?id=16317
>> https://issues.dlang.org/show_bug.cgi?id=16189
>> https://issues.dlang.org/show_bug.cgi?id=17949
>> https://issues.dlang.org/show_bug.cgi?id=15511
>> https://issues.dlang.org/show_bug.cgi?id=16107
>
> Thank you. I have tagged them with the "Industry" keyword, which is for issues raised by people using D in industrial situations. The last one (16107) is marked as resolved and appears to have been fixed.

Thanks, sorry that was my mistake (posting in a hurry). It was this bug:

https://issues.dlang.org/show_bug.cgi?id=16108
(hardly what I would call a blocker, but I didn't make the list)

Looking at bugzilla I see this is also now fixed but we were on 2.074 at the time. Sorry I don't have more specific details, it was hard enough just to get some devs to create bugzilla accounts let alone find existing tickets or raise new tickets.

As I was trying to point out before but unfortunately came across as just a negative git; many developers agreed that D is a fantastic language, but they have zero interest in developing or even raising tickets when D doesn't just work. I think the main reason for this is because they expect a C++/Python like experience where your rarely hit a compiler/interpreter bug.

This seems to be the majority of developers I talk to, so it is a hard sell, but on the bright side I'm starting to see more and more internal tools here written in D :)

Cheers,
Norm

On Sunday, 18 March 2018 at 04:25:48 UTC, Manu wrote:
> What is so hard about implementing a pow intrinsic that CTFE can use?
> It's ridiculous that we can't CTFE any non-linear function...
> It's one of those blocker bugs that's been there almost 10 years.

Well, there is this PR : https://github.com/dlang/dmd/pull/8071

On 3/17/2018 9:25 PM, Manu wrote:
> What is so hard about implementing a pow intrinsic that CTFE can use?

https://github.com/dlang/dmd/pull/8071


> It's one of those blocker bugs that's been there almost 10 years.

It's one that seems to engender lots of comments, but no action.

(BTW, there's a way to do it without the CTFE fix. One can use the approach I've always used in the past for C, which is write a separate program to generate the tables. This was used in the DMD build, and was gradually replaced with CTFE. It still exists in the backend, which is still in C++.)

On Friday, 23 March 2018 at 09:37:26 UTC, Norm wrote:

> I think the main reason for this is because they expect a C++/Python like experience where your rarely hit a compiler/interpreter bug.

What happens if they found a bug in C++ or Python?

--
/Jacob Carlborg

On Friday, 23 March 2018 at 09:37:26 UTC, Norm wrote:
>
> I think the main reason for this is because they expect a C++/Python like experience where your rarely hit a compiler/interpreter bug.
>
> Cheers,
> Norm

What do you mean?

https://gcc.gnu.org/bugzilla/buglist.cgi?component=c%2B%2B&product=gcc&resolution=---

On 23.03.2018 13:06, Jacob Carlborg wrote:
> On Friday, 23 March 2018 at 09:37:26 UTC, Norm wrote:
> 
>> I think the main reason for this is because they expect a C++/Python like experience where your rarely hit a compiler/interpreter bug.
> 
> What happens if they found a bug in C++ or Python?
> 
> -- 
> /Jacob Carlborg

The process is very similar to when they hit it in DMD:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51664

This is an anecdote, of course, but for perspective: this bug was known for ~7 years before I posted the duplicate and it took another 5 years from my report until it was fixed.

Note that the first answer I got was "I don't think [this report] is valid". I guess it is easier to not blame the compiler if you are not sure whether you understand the language definition correctly.

On 23 March 2018 at 01:36, Nick Sabalausky (Abscissa) via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 03/23/2018 03:35 AM, Jordan Wilson wrote:
>>
>>
>> I suppose it's about finding that balance between growing the D user base, and trying to get said user base to give back.
>>
>> Say I was offered a car with no windscreen...I have 3 responses:
>> 1. Cool! I'll put in a windscreen myself, as this car has a great engine.
>> 2. Thanks. This car does a great job getting from a to b, pity about all
>> these bugs flying in my face though. Wish I knew more about windscreens.
>> 3. No thank you, I'll just stick with the train. Nice spinner rims, btw.
>>
>> Regarding D, I fall into (2), but sometimes I wonder if catching the train
>> would be easier...
>
>
> I used to be (2) with D, but that was something like ten years ago. At this point, it's more like a brand new sedan, well-built, reasonably priced, great mileage, a few minor things I've tweaked or done differently if I had a magic wand, but otherwise a car that leaves me wondering "Why are people whining about the lack of spinner support and iPhone whiz-bangery? Big effing deal."
>
> That's NOT a comment on Manu's OP here, of course. Something like "Why is x^^y *still* not CTFE-able???" is the kind of thing I completely sympathize with. Can't imagine that sort of thing being a blocker though, especially if I were still doing a lot of work in C or C++.

Like, in this particular project, being able to generate all tables at compile time is the thing that distinguishes the D code from the C++ code; it's the *whole point*... If I have to continue to generate tables offline and paste big tables of data in the source code (and then re-generate them manually when I change something); then situation is identical to C++, therefore, stick with C++.\

This is the practical reality with a lot of my outstanding issues with D; we've covered an awful lot of ground in 10 years, but basic outstanding issues like not being able to pass an rvalue as ref makes the D code longer and uglier than the C++ code it's meant to replace. There's no argument that can be made that advocates leaving C++ (established, entrenched) for an emerging language like D, when the case-study is longer+uglier in D.

My experience today is; D can generate machinery that C++ can't even
dream of, which is awesome, but that usually represents a tiny
fraction of your code, usually packed up in a tight little box. For
the majority of 'just code that you write', D's biggest contributors
are ranges+slices, but in my experience (migrating C++ to D), that
stuff doesn't emerge until a couple of iterations after migration.
The initial migration focuses on translation, and when super-simple
code gets longer and uglier, that's not a good look, and tends to stop
people dead in their tracks.
And it's basically inexcusable. The most common frequent code that you
write shouldn't be longer/uglier in D. We need to be able to
demonstrate that the common case gets better (or at least stays the
same) just as much as the obscure and contrived case.