On Tue, Oct 05, 2021 at 07:36:28PM +0200, ag0aep6g via Digitalmars-d-announce wrote: [...]
> > > On Monday, 4 October 2021 at 22:40:19 UTC, Temtaime wrote:
> > > > What is really discourages me that persons like Walter instead of making D great just do nothing helpful.
[...]
> It's absolutely true that many reported issues don't get fixed for *years*.  And that very much includes serious bugs. As far as I can tell, it's also true that Walter prioritizes new features instead (ImportC is the latest fad).
> 
> I sympathize with Temtaime. Their criticism wasn't sugar-coated, but it is constructive and it is valid in my opinion.

I don't agree with the tone of the criticism, but I do sympathize with the sentiment.  The sad reality is that it's much more fun to write new code than to debug old code.  Especially when you just had a cool idea that feels like it would revolutionize everything.  And it very well might do just that; but in the meantime, "boring" stuff like fixing bugs in the current (probably hairy, messy, unclean) code gets neglected.

This is a particularly pronounced problem in groups consisting mostly of experts or highly-experienced people.  Everybody wants to do the cool, innovative stuff, nobody feels like doing the boring grunt work.  Worse yet, in high-expertise areas like debugging the D compiler even those who are willing to do the grunt work may not actually feel qualified enough to do it.

But grunt work is just as necessary as the innovative, ground-breaking stuff.  *Somebody* has to step up and be willing to do it.  It's a thankless, unrewarding job, but a very necessary one.


T

-- 
Don't modify spaghetti code unless you can eat the consequences.

On Tuesday, 5 October 2021 at 17:36:28 UTC, ag0aep6g wrote:
> On 05.10.21 11:28, Imperatorn wrote:
>> On Tuesday, 5 October 2021 at 07:55:11 UTC, FeepingCreature wrote:
>>> On Monday, 4 October 2021 at 22:40:19 UTC, Temtaime wrote:
>>>>[...]
>>> This is just uncalled for. I'm sure you can express what you mean without pointlessly and wrongly insulting the *reason we have this language,* a person who put more than twenty years of their life into this project.
>> 
>> Agreed.
>> 
>> It's totally OK to criticize, but one should do it in a constructive way
>
> Temtaime said that Walter is setting the wrong priorities. Saying that he is doing "nothing useful" is a bit polemic, of course, but that probably stems from frustration. In context, it's hardly an "insult".
>
> It's absolutely true that many reported issues don't get fixed for *years*. And that very much includes serious bugs. As far as I can tell, it's also true that Walter prioritizes new features instead (ImportC is the latest fad).
>
> I sympathize with Temtaime. Their criticism wasn't sugar-coated, but it is constructive and it is valid in my opinion.

Idk, maybe it's just poorly worded. I can also sympathize, but saying someone is doing nothing useful is over the limit in my book.

We all have stuff to deal with and making the right choices can be challenging. Just saying...

On 10/5/2021 8:57 AM, Steven Schveighoffer wrote:
> On 10/4/21 6:40 PM, Temtaime wrote:
>> https://issues.dlang.org/show_bug.cgi?id=22115 was created for no reason and fixed same day.
> 
> Aside from the tasteless (and incorrect) attack here, creating an issue, even for a small change, puts something into the changelog automatically.
> 
> So there is a reason to open an issue for a PR you are just about to merge. In fact, sometimes it's noted as a prerequisite for a PR to reference a given issue.

Right. And the reason was also given in the bug report - enabling the front end to be written in a more readable manner.

On 10/5/2021 10:36 AM, ag0aep6g wrote:
> it's also true that Walter prioritizes new features instead (ImportC is the latest fad)

ImportC resolves a long standing serious issue where multiple other substantial attempts at solving it have fallen short over the years. Unfortunately, ImportC is useless if it only half works. It has to work with existing C headers, which is why I'm concentrating on it to get to that point. Lack of ImportC has wasted a *lot* of developer time, making it a high leverage investment of time.

Just think of all the time lost doing manual conversion of .h files, and then doing them again and again as they evolve. Then not one, not two, but *three* different automated programs were developed to try and resolve this (one of which I wrote). Then think of all the projects *not* done because of the barrier of trying to deal with several thousand lines of .h files.

The Diemos project was an effort to crowdsource conversion of .h files to D, but it just was not adequate.

In summary, ImportC is totally worth the effort. I should have done it 15 years ago.

On Sunday, 10 October 2021 at 23:11:56 UTC, Walter Bright wrote:
> On 10/5/2021 10:36 AM, ag0aep6g wrote:
>> it's also true that Walter prioritizes new features instead (ImportC is the latest fad)
>
> ImportC resolves a long standing serious issue where multiple other substantial attempts at solving it have fallen short over the years. Unfortunately, ImportC is useless if it only half works. It has to work with existing C headers, which is why I'm concentrating on it to get to that point. Lack of ImportC has wasted a *lot* of developer time, making it a high leverage investment of time.
>
> Just think of all the time lost doing manual conversion of .h files, and then doing them again and again as they evolve. Then not one, not two, but *three* different automated programs were developed to try and resolve this (one of which I wrote). Then think of all the projects *not* done because of the barrier of trying to deal with several thousand lines of .h files.
>
> The Diemos project was an effort to crowdsource conversion of .h files to D, but it just was not adequate.
>
> In summary, ImportC is totally worth the effort. I should have done it 15 years ago.

I agree 100%, ImportC is a needed feature

Zig people understood that and made it one of their strength

C ecosystem is way too big to just ignore it, we seen it with rust, people are not interested in rewriting their libraries in the *insert what's trending* language, they want to take their luggage with them, and they are right, ImportC enables that

On Sunday, 10 October 2021 at 23:11:56 UTC, Walter Bright wrote:
> ImportC resolves a long standing serious issue where multiple other substantial attempts at solving it have fallen short over the years. Unfortunately, ImportC is useless if it only half works. It has to work with existing C headers, which is why I'm concentrating on it to get to that point. Lack of ImportC has wasted a *lot* of developer time, making it a high leverage investment of time.
>
> [...]

Meanwhile @live is in the language, and it's half-baked. Then there's preview switches that will linger on into perpetuity; DIPs' implementations that haven't been finished.

On Sunday, 10 October 2021 at 23:36:56 UTC, surlymoor wrote:
>
> Meanwhile @live is in the language, and it's half-baked. Then there's preview switches that will linger on into perpetuity; DIPs' implementations that haven't been finished.

And Walter has prioritized this issue over those. No matter what he works on, people will moan that he isn’t working on something else. Maybe we should clone him.

On Monday, 11 October 2021 at 00:34:28 UTC, Mike Parker wrote:
> On Sunday, 10 October 2021 at 23:36:56 UTC, surlymoor wrote:
>>
>> Meanwhile @live is in the language, and it's half-baked. Then there's preview switches that will linger on into perpetuity; DIPs' implementations that haven't been finished.
>
> And Walter has prioritized this issue over those. No matter what he works on, people will moan that he isn’t working on something else. Maybe we should clone him.

My cousin has a vat filled with neon green liquid. Just let me know.