www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Send me your list of D gripes and wishes

reply Mike Parker <aldacron gmail.com> writes:
Everyone in the D community has their own reasons for being here. 
We each have our own goals and plans, our own likes and dislikes, 
our own expectations and tolerance levels when those expectations 
go unmet, and so on.

When any given person's expectations aren't met over a period of 
time, whatever that period may be, frustration is understandable. 
But ranting in the forums about how Walter, or anyone involved in 
furthering D's development, doesn't care about the community is 
both unwarranted and unproductive. None of us would be here if we 
didn't care.

Discussions of D's problems and weaknesses, and the pet peeves of 
different D users, are scattered out across the forums, the 
community Discord, the IRC channel, Slack, and who knows where. 
When someone makes a general complaint in the forums, there's a 
certain amount of surprise and frustration when Walter asks for 
specific Bugzilla issues or links to past discussions, as if he's 
expected to have an eidetic memory.

The issues that you encounter in your code and frequently discuss 
with others in any given communications channel may be at the 
front of your mind, but that doesn't mean they are at the front 
of anyone else's mind. I certainly don't remember every complaint 
I've read about any given D feature. The issues at the front of 
my mind usually have nothing to do with any of that. I'm totally 
with Walter when he asks for specific details, or links to past 
discussions or Bugzilla issues. Otherwise, it's just noise.

So I have a proposal. Let's take a first step to bring some order 
to the chaos.

I invite every member of the D community to email me at 
social dlang.org with your specific gripes about the current 
state of D and the things you'd like to see in the future 
(changes, new features, etc). But don't write in general terms. 
Be specific.

If your code is breaking every release, how is it breaking? If a 
certain language feature isn't working the way you expect, how do 
you expect it to work? Which unresolved issues have forced you 
into annoying workarounds, and what are those workarounds? What 
missing features would make your life easier? What are some 
important but unmaintained projects in the ecosystem that need 
attention?

Any D feature, any D tool or project in the ecosystem, is fair 
game. The important point here though is _please be as detailed 
and specific as you can_. Include any relevant links to Bugzilla 
issues or past forum discussions. I can always ask for more 
detail if I need to, but you'll save both of us time if you 
include it up front.

I will take this information as it comes in and look for 
commonalities and establish priorities. Over time, this should 
help me compile a list of actionable items that I can bring to 
future foundation meetings, and give us a starting point for 
serious discussions with community members on how we can solve 
specific issues that aren't so easily solved. And it will give 
the ecosystem management team a head start once they get off the 
ground. Moreover, I can post the list somewhere so that everyone 
can see it, and we'll all have a common point of reference and 
see the progress being made as issues are resolved.

By doing this, we can work to align the maintainers' goals with 
those of the community. I can't promise that Walter or anyone 
else on the team will agree that any given issue should be a 
priority, but I'm sure we'll identify a number of them. Nor can I 
promise that we'll be able to resolve any given issue in a 
reasonable time frame, given our lack of resources, but having 
them identified and prioritized is an important step toward 
ultimately resolving them.

I want to remind everyone that we're in this together. I would 
love it if we had a dedicated team of engineers who could 
methodically work through task lists. But we don't. Razvan and 
Dennis are doing a good bit of work beyond their primary job 
descriptions, like implementing approved DIPs that have been 
languishing unimplemented, but they don't have infinite time. So 
at some point, we'll need a few people to step up in one way or 
another.

But for now, just email me. Everyone in the D community who has 
the time and ability to post in the forums also has the time and 
ability to send me an email detailing their complaints. So 
please, don't be silent. Just redirect all that energy you've put 
into internet rants, or kept bottled inside as the case may be, 
into an email telling me all about your pain.

__PLEASE NOTE__: I won't be looking for your lists in this 
thread. If it turns into one of those multipage threads, I don't 
want to have to pick through every post looking for the details. 
__Please email me__. Then I can keep everything in one place with 
nice tags that make it easy for me to reference.
Dec 24 2022
next sibling parent reply ag0aep6g <anonymous example.com> writes:
On Saturday, 24 December 2022 at 13:46:33 UTC, Mike Parker wrote:

 __PLEASE NOTE__: I won't be looking for your lists in this 
 thread. If it turns into one of those multipage threads, I 
 don't want to have to pick through every post looking for the 
 details. __Please email me__. Then I can keep everything in one 
 place with nice tags that make it easy for me to reference.


A long time ago, I found a bug. Being a good little 
user/contributor, I reported it. It's here: 
https://issues.dlang.org/show_bug.cgi?id=15086

I then had to painfully convince the leadership that it is indeed 
a bug. I'm still not sure if Walter recognizes the actual issue.

Years later, Walter told us to post to the forums if we want to 
"get action" on issues. I did that. Nothing happened. [1][2]

Now you're asking me to email you. I'm not going to jump through 
that hoop. I have no reason to believe that this new channel is 
going to be more effective than the previous ones. Also, I want 
my airing of grievances to be public, not neatly hidden away in 
your personal emails.

You have a Bugzilla database full of bugs. You need to figure out 
how to fix them. You do not need new, less transparent channels 
to report them.

If Bugzilla seems too big to handle, that should tell you: Stop 
adding new features; start chipping away at the bug mountain.


[1] https://forum.dlang.org/post/rbeab9$20l1$1 digitalmars.com
[2] https://forum.dlang.org/post/rtppnb$3083$1 digitalmars.com
Dec 24 2022
next sibling parent Mike Parker <aldacron gmail.com> writes:
On Saturday, 24 December 2022 at 14:46:42 UTC, ag0aep6g wrote:

 Now you're asking me to email you. I'm not going to jump 
 through that hoop. I have no reason to believe that this new 
 channel is going to be more effective than the previous ones. 
 Also, I want my airing of grievances to be public, not neatly 
 hidden away in your personal emails.


Whether you participate or not is up to you, but I want to 
reiterate that I'll be publishing everything I receive (not sure 
yet of the format). The issues won't be "hidden away" in my 
personal emails. The point here is for me to be able to stay 
organized. Anyone who sends me an email is free to copy and paste 
it in the forums, or shout it to the world if it isn't included 
on the public list.

And I encourage everyone, whatever your past experience, to think 
of this as a clean slate. And remember, this isn't just about 
Bugzilla issues.

Again, I can't promise Walter will agree any given complaint is a 
bug, or that there will be general agreement that your priorities 
should be broader priorities, or that any given issue will ever 
be resolved. However, I do believe that with enough feedback, 
this should help us to establish a roadmap going forward.
Dec 24 2022
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/24/2022 6:46 AM, ag0aep6g wrote:

 On Saturday, 24 December 2022 at 13:46:33 UTC, Mike Parker wrote:

 __PLEASE NOTE__: I won't be looking for your lists in this thread. If it turns 
 into one of those multipage threads, I don't want to have to pick through 
 every post looking for the details. __Please email me__. Then I can keep 
 everything in one place with nice tags that make it easy for me to reference.


 
 A long time ago, I found a bug. Being a good little user/contributor, I
reported 
 it. It's here: https://issues.dlang.org/show_bug.cgi?id=15086
 
 I then had to painfully convince the leadership that it is indeed a bug. I'm 
 still not sure if Walter recognizes the actual issue.


Your report was not ignored. It's that changing it would break existing code, 
something I get routinely excoriated about.

The -mv switch was added to deal with this problem, and is mentioned in the 
comments on the issue.

https://dlang.org/dmd-windows.html#switch-mv

There have also been two PRs by marler8997 about it.

https://github.com/dlang/dmd/pull/7778
https://github.com/dlang/dmd/pull/7878

though I'm not sure why he closed the second.
Dec 24 2022
next sibling parent Paul Backus <snarwin gmail.com> writes:
On Saturday, 24 December 2022 at 19:53:34 UTC, Walter Bright 
wrote:

 There have also been two PRs by marler8997 about it.

 https://github.com/dlang/dmd/pull/7778
 https://github.com/dlang/dmd/pull/7878

 though I'm not sure why he closed the second.


It seems pretty clear to me from the discussion: he closed it 
because Andrei told him that the rationale given for the PR was 
not convincing (reportedly after "a long discussion with 
 WalterBright"), and he did not feel like arguing the point.
Dec 24 2022
prev sibling parent reply ag0aep6g <anonymous example.com> writes:
On Saturday, 24 December 2022 at 19:53:34 UTC, Walter Bright 
wrote:

 Your report was not ignored.


I didn't say it was.


 It's that changing it would break existing code, something I 
 get routinely excoriated about.


You use that excuse a lot, and it rarely truly applies. It 
doesn't apply here. People complain when you break their valid 
code. They don't complain when you make their buggy code fail to 
compile. Or rather: If someone complains about that, you should 
ignore them.


 The -mv switch was added to deal with this problem, and is 
 mentioned in the comments on the issue.

 https://dlang.org/dmd-windows.html#switch-mv


That linked documentation is buggy itself. "path/filename" is 
missing in the syntax line. Someone should fix that, or at least 
file an issue. Not me though.

Also, that switch seems to be meant to ease the transition for 
when the bug gets fixed. But the bug hasn't been fixed.


 There have also been two PRs by marler8997 about it.

 https://github.com/dlang/dmd/pull/7778
 https://github.com/dlang/dmd/pull/7878

 though I'm not sure why he closed the second.


Really? Andrei argued against fixing the issue. Jonathan simply 
accepted that. Andrei was wrong, of course, but we can't blame 
Jonathan for yielding to the (supposedly benevolent) dictator.

For me, dealing with D's leadership has been an infuriating 
experience time and time again. It's the one reason why I have 
dialed back my contributions to near zero. There is a lot to fix 
in D, but when I have to fight for the privilege of cleaning up 
after you guys while you refuse to even recognize your own bugs, 
that's just not worth it.

I can't say for sure that Jonathan Marler stepped away for the 
same reason, but I am sure that poor handling of contributors has 
cost D a lot of talent.
Dec 24 2022
next sibling parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Saturday, 24 December 2022 at 23:22:47 UTC, ag0aep6g wrote:

 On Saturday, 24 December 2022 at 19:53:34 UTC, Walter Bright 
 wrote:

 Your report was not ignored.


 I didn't say it was.


 It's that changing it would break existing code, something I 
 get routinely excoriated about.


 You use that excuse a lot, and it rarely truly applies. It 
 doesn't apply here. People complain when you break their valid 
 code. They don't complain when you make their buggy code fail 
 to compile. Or rather: If someone complains about that, you 
 should ignore them.


 The -mv switch was added to deal with this problem, and is 
 mentioned in the comments on the issue.

 https://dlang.org/dmd-windows.html#switch-mv


 That linked documentation is buggy itself. "path/filename" is 
 missing in the syntax line. Someone should fix that, or at 
 least file an issue. Not me though.

 Also, that switch seems to be meant to ease the transition for 
 when the bug gets fixed. But the bug hasn't been fixed.


 There have also been two PRs by marler8997 about it.

 https://github.com/dlang/dmd/pull/7778
 https://github.com/dlang/dmd/pull/7878

 though I'm not sure why he closed the second.


 Really? Andrei argued against fixing the issue. Jonathan simply 
 accepted that. Andrei was wrong, of course, but we can't blame 
 Jonathan for yielding to the (supposedly benevolent) dictator.

 For me, dealing with D's leadership has been an infuriating 
 experience time and time again. It's the one reason why I have 
 dialed back my contributions to near zero. There is a lot to 
 fix in D, but when I have to fight for the privilege of 
 cleaning up after you guys while you refuse to even recognize 
 your own bugs, that's just not worth it.

 I can't say for sure that Jonathan Marler stepped away for the 
 same reason, but I am sure that poor handling of contributors 
 has cost D a lot of talent.



"dmd -c main.d && dmd -c foo.d". Andrei didn't think this 
discrepency was worth fixing. I was dumbfounded by this response 
and still am to this day.

I have alot of memories like this one from when I use to try to 
fix issues with D. I have a passion about my tools being correct, 
but, I found myself spending more time arguing with people than 
writing code. It was miserable.

Now I'm able to spend time doing what I love, writing 
robust-maintainable software with good tooling. When there's an 
issue with my toolchain, I'm able to submit a fix and it gets 
merged. It's night and day for me. I don't understand why there's 
was always so much disagreement/resistance when I contributed to 
D, I suppose I may never know. No hard feelings though, hope 
y'all are doing well.
Dec 24 2022
next sibling parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
Yeah, we have had a real problem with engaging contributors long-term. 
For instance even Walter has been blocking himself contributing lately.

I'm hoping to see this improve, Razvan does an amazing job as PR manager 
so far which has been a real boost to getting stuff in.

The desire is there to fix things.
Dec 24 2022
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/24/2022 7:10 PM, Jonathan Marler wrote:

 I have alot of memories like this one from when I use to try to fix issues
with 
 D. I have a passion about my tools being correct, but, I found myself spending 
 more time arguing with people than writing code. It was miserable.


I don't like arguing, either. I often spend more time arguing about a PR than 
developing it. I understand how frustrating this can be. I suppose it just
comes 
with the territory when there are a lot of stakeholders doing reviews.



 Now I'm able to spend time doing what I love, writing robust-maintainable 
 software with good tooling. When there's an issue with my toolchain, I'm able
to 
 submit a fix and it gets merged. It's night and day for me. I don't understand 
 why there's was always so much disagreement/resistance when I contributed to
D, 
 I suppose I may never know. No hard feelings though, hope y'all are doing well.


Your track record of successful merges is also very, very good and you should
be 
proud of your achievements:

https://github.com/dlang/dmd/pulls?page=1&q=is%3Apr+author%3Amarler8997+is%3Aclosed
Dec 24 2022
next sibling parent reply GrimMaple <grimmaple95 gmail.com> writes:
On Sunday, 25 December 2022 at 07:47:19 UTC, Walter Bright wrote:

 On 12/24/2022 7:10 PM, Jonathan Marler wrote:

 I have alot of memories like this one from when I use to try 
 to fix issues with D. I have a passion about my tools being 
 correct, but, I found myself spending more time arguing with 
 people than writing code. It was miserable.


 I don't like arguing, either. I often spend more time arguing 
 about a PR than developing it. I understand how frustrating 
 this can be. I suppose it just comes with the territory when 
 there are a lot of stakeholders doing reviews.


If you don't like arguing, then just stop arguing.


 Now I'm able to spend time doing what I love, writing 
 robust-maintainable software with good tooling. When there's 
 an issue with my toolchain, I'm able to submit a fix and it 
 gets merged. It's night and day for me. I don't understand why 
 there's was always so much disagreement/resistance when I 
 contributed to D, I suppose I may never know. No hard feelings 
 though, hope y'all are doing well.


 Your track record of successful merges is also very, very good 
 and you should be proud of your achievements:

 https://github.com/dlang/dmd/pulls?page=1&q=is%3Apr+author%3Amarler8997+is%3Aclosed


Getting PRs in should be an achievement, it should be a part of 
working process. I also heavily dislike how you argue the 
experience of getting PRs in by how much of them exist. If people 
tell you their experience sucked, then you should listen to it 
and try to improve it.
Dec 25 2022
next sibling parent reply GrimMaple <grimmaple95 gmail.com> writes:
On Sunday, 25 December 2022 at 15:58:55 UTC, GrimMaple wrote:

 On Sunday, 25 December 2022 at 07:47:19 UTC, Walter Bright 
 wrote:

 On 12/24/2022 7:10 PM, Jonathan Marler wrote:

 I have alot of memories like this one from when I use to try 
 to fix issues with D. I have a passion about my tools being 
 correct, but, I found myself spending more time arguing with 
 people than writing code. It was miserable.


 I don't like arguing, either. I often spend more time arguing 
 about a PR than developing it. I understand how frustrating 
 this can be. I suppose it just comes with the territory when 
 there are a lot of stakeholders doing reviews.


 If you don't like arguing, then just stop arguing.


 Now I'm able to spend time doing what I love, writing 
 robust-maintainable software with good tooling. When there's 
 an issue with my toolchain, I'm able to submit a fix and it 
 gets merged. It's night and day for me. I don't understand 
 why there's was always so much disagreement/resistance when I 
 contributed to D, I suppose I may never know. No hard 
 feelings though, hope y'all are doing well.


 Your track record of successful merges is also very, very good 
 and you should be proud of your achievements:

 https://github.com/dlang/dmd/pulls?page=1&q=is%3Apr+author%3Amarler8997+is%3Aclosed


 Getting PRs in should be an achievement, it should be a part of 
 working process. I also heavily dislike how you argue the 
 experience of getting PRs in by how much of them exist. If 
 people tell you their experience sucked, then you should listen 
 to it and try to improve it.


Of course, I meant it shouldn't be an achievement.
Dec 25 2022
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/25/2022 7:59 AM, GrimMaple wrote:

 Of course, I meant it shouldn't be an achievement.


Writing quality work is an achievement.
Dec 25 2022
prev sibling next sibling parent bachmeier <no spam.net> writes:
On Sunday, 25 December 2022 at 15:58:55 UTC, GrimMaple wrote:

 On Sunday, 25 December 2022 at 07:47:19 UTC, Walter Bright 
 wrote:

 On 12/24/2022 7:10 PM, Jonathan Marler wrote:

 I have alot of memories like this one from when I use to try 
 to fix issues with D. I have a passion about my tools being 
 correct, but, I found myself spending more time arguing with 
 people than writing code. It was miserable.


 I don't like arguing, either. I often spend more time arguing 
 about a PR than developing it. I understand how frustrating 
 this can be. I suppose it just comes with the territory when 
 there are a lot of stakeholders doing reviews.


 If you don't like arguing, then just stop arguing.


I think the point Walter's making is that he has to go through 
the same review process, and it sucks for him too. I take the 
last sentence to mean it's caused by the current system giving 
veto power to many people.

My impression is that in the early days functionality was more 
important than getting it right. That's how things like std.json 
ended up in the standard library. Then it changed to "it's got to 
be perfect" and that causes frustration and makes willing 
contributors quit.

The answer is to make major changes to the development process.
Dec 25 2022
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/25/2022 7:58 AM, GrimMaple wrote:

 Getting PRs in should be an achievement, it should be a part of working
process.


We do have a high bar for accepting PRs. The quality of ones that are accepted 
has increased significantly over the years.



 I also heavily dislike how you argue the experience of getting PRs in by how 
 much of them exist.


I wasn't arguing. I was pointing out their track record of success.


 If people tell you their experience sucked, then you should 
 listen to it and try to improve it.


I'm listening.
Dec 25 2022
parent reply claptrap <clap trap.com> writes:
On Sunday, 25 December 2022 at 22:53:23 UTC, Walter Bright wrote:

 On 12/25/2022 7:58 AM, GrimMaple wrote:

 I also heavily dislike how you argue the experience of getting 
 PRs in by how much of them exist.


 I wasn't arguing. I was pointing out their track record of 
 success.


seriously? "I wasn't arguing I was just pointing out why they are 
wrong to feel the way they do?"



 If people tell you their experience sucked, then you should 
 listen to it and try to improve it.


 I'm listening.


No you're not. If someone says "I find this process incredibly 
frustrating" and you reply "but you have 100% success rate, and 
that's better than me", you are firstly telling them that they 
are wrong to feel the way they do, and that secondly you have it 
worse.
Dec 25 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/25/2022 4:12 PM, claptrap wrote:

 If someone says "I find this process incredibly frustrating" and 
 you reply "but you have 100% success rate, and that's better than me", you are 
 firstly telling them that they are wrong to feel the way they do, and that 
 secondly you have it worse.


Or asking for an explanation.
Dec 25 2022
parent claptrap <clap trap.com> writes:
On Monday, 26 December 2022 at 01:30:48 UTC, Walter Bright wrote:

 On 12/25/2022 4:12 PM, claptrap wrote:

 If someone says "I find this process incredibly frustrating" 
 and you reply "but you have 100% success rate, and that's 
 better than me", you are firstly telling them that they are 
 wrong to feel the way they do, and that secondly you have it 
 worse.


 Or asking for an explanation.


"I dont understand why you feel that way could you explain more"

That's asking for an explanation.

"The nearly 100% track record of successful contributions is at 
odds with it being impossible to contribute. Their successful PR 
rate is better than mine. I don't know what to say."

That is telling people they are wrong. (plus a strawman). Plus 
the "I dont know what to say" implies frustration at the 
complaint rather that interest.
Dec 26 2022
prev sibling parent reply Paul Backus <snarwin gmail.com> writes:
If multiple contributors with significant track records of 
success are telling you that the frustration of working with D's 
leadership has driven them to stop contributing, how many 
potential contributors would you estimate have given up before 
even getting to that point?

D's lack of manpower is often lamented on this forum. If our 
current approach to leadership and governance is costing us 
manpower, that seems to me like a serious bug in the D project, 
which we ought to prioritize fixing.
Dec 25 2022
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/25/2022 9:16 AM, Paul Backus wrote:

 D's lack of manpower is often lamented on this forum. If our current approach
to 
 leadership and governance is costing us manpower, that seems to me like a 
 serious bug in the D project, which we ought to prioritize fixing.


The nearly 100% track record of successful contributions is at odds with it 
being impossible to contribute. Their successful PR rate is better than mine. I 
don't know what to say.
Dec 25 2022
next sibling parent claptrap <clap trap.com> writes:
On Sunday, 25 December 2022 at 22:50:41 UTC, Walter Bright wrote:

 On 12/25/2022 9:16 AM, Paul Backus wrote:

 D's lack of manpower is often lamented on this forum. If our 
 current approach to leadership and governance is costing us 
 manpower, that seems to me like a serious bug in the D 
 project, which we ought to prioritize fixing.


 The nearly 100% track record of successful contributions is at 
 odds with it being impossible to contribute. Their successful 
 PR rate is better than mine. I don't know what to say.


Nobody in this thread said it was impossible to contribute. What 
they said is that is an incredibly frustrating process.
Dec 25 2022
prev sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Sunday, 25 December 2022 at 22:50:41 UTC, Walter Bright wrote:

 On 12/25/2022 9:16 AM, Paul Backus wrote:

 D's lack of manpower is often lamented on this forum. If our 
 current approach to leadership and governance is costing us 
 manpower, that seems to me like a serious bug in the D 
 project, which we ought to prioritize fixing.


 The nearly 100% track record of successful contributions is at 
 odds with it being impossible to contribute. Their successful 
 PR rate is better than mine. I don't know what to say.


Neither I nor anyone else in this thread has claimed that D is 
*impossible* to contribute to, merely that contributing to D is 
more frustrating than it needs to be.

Do you dispute this? In your view, is it the case that 
contributing to D is, at this very moment, as smooth and 
frictionless a process as it could ever possibly be, without 
compromising on quality?
Dec 25 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/25/2022 4:16 PM, Paul Backus wrote:

 Do you dispute this? In your view, is it the case that contributing to D is,
at 
 this very moment, as smooth and frictionless a process as it could ever
possibly 
 be, without compromising on quality?


I don't know how to have quality with a frictionless process. It's like that
old 
maxim:

1. quality
2. cost
3. time

Pick two.
Dec 25 2022
next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Monday, 26 December 2022 at 01:29:40 UTC, Walter Bright wrote:

 On 12/25/2022 4:16 PM, Paul Backus wrote:

 Do you dispute this? In your view, is it the case that 
 contributing to D is, at this very moment, as smooth and 
 frictionless a process as it could ever possibly be, without 
 compromising on quality?


 I don't know how to have quality with a frictionless process. 
 It's like that old maxim:

 1. quality
 2. cost
 3. time

 Pick two.


I agree that the friction cannot be reduced to zero. I still 
think it is probably possible to reduce it to, say, 50% of its 
current amount, without compromising on quality.

In the same way that software can have both essential complexity 
and accidental complexity [1], a process can have both essential 
friction and accidental friction. What I and others are 
suggesting is that a lot of the friction in D's current 
contribution process is accidental, not essential, and could be 
removed without making the process less effective.

For example: Jonathan Marler says he spent "more time arguing 
with people than writing code." How much of that argument do you 
think was productive, and how much was unproductive? Github 
provides no shortage of moderation tools [2]; I am sure that if 
we put our minds to it, we can work out some policies for using 
those tools to weed out unproductive arguments and keep PR and 
issue discussions focused.

[1] http://worrydream.com/refs/Brooks-NoSilverBullet.pdf
[2] 
https://docs.github.com/en/communities/moderating-comments-and-conversations
Dec 25 2022
next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 26/12/2022 4:57 PM, Paul Backus wrote:

 I agree that the friction cannot be reduced to zero. I still think it is 
 probably possible to reduce it to, say, 50% of its current amount, 
 without compromising on quality.


Here is a big one: remove the damn style checkers!

Automatic format on PR and commit right back into remote branch.

Problem solved. No more CI errors.
Dec 25 2022
next sibling parent Mike Parker <aldacron gmail.com> writes:
On Monday, 26 December 2022 at 04:06:05 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 On 26/12/2022 4:57 PM, Paul Backus wrote:

 I agree that the friction cannot be reduced to zero. I still 
 think it is probably possible to reduce it to, say, 50% of its 
 current amount, without compromising on quality.


 Here is a big one: remove the damn style checkers!

 Automatic format on PR and commit right back into remote branch.

 Problem solved. No more CI errors.


I'd like to interject here to please ask everyone who has any 
ideas or suggestions on specific steps we can take to improve the 
contribution process to please do as I asked and email them to me 
so that I can easily keep track of them.
Dec 25 2022
prev sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Monday, 26 December 2022 at 04:06:05 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 On 26/12/2022 4:57 PM, Paul Backus wrote:

 I agree that the friction cannot be reduced to zero. I still 
 think it is probably possible to reduce it to, say, 50% of its 
 current amount, without compromising on quality.


 Here is a big one: remove the damn style checkers!

 Automatic format on PR and commit right back into remote branch.

 Problem solved. No more CI errors.


Genuine curiosity, because maybe you have experience with that 
that I don't: how would this work with multi-patch PRs?

I ask because, personally, I don't find CI style checks to be a 
problem, especially if there's an easy way to run a local tool to 
check and/or fix things on a patch-by-patch basis.  That way I 
can make sure that the code is both style-compliant and that it 
"reads" well for me.  OTOH I do have a bit of a problem with the 
idea of an external system rewriting my code for me, especially 
if the result is messy -- like a series of patches that violate 
code style followed by an auto-generated fix-the-style patch.

Maybe that's too fussy ... ?  But my experience has tended to be 
that when people entirely outsource style-compliance to external 
tooling, you wind up with a lot of quite ugly code and 
harder-to-follow patches.
Dec 31 2022
next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 31/12/2022 9:36 PM, Joseph Rushton Wakeling wrote:

 On Monday, 26 December 2022 at 04:06:05 UTC, Richard (Rikki) Andrew 
 Cattermole wrote:

 On 26/12/2022 4:57 PM, Paul Backus wrote:

 I agree that the friction cannot be reduced to zero. I still think it 
 is probably possible to reduce it to, say, 50% of its current amount, 
 without compromising on quality.


 Here is a big one: remove the damn style checkers!

 Automatic format on PR and commit right back into remote branch.

 Problem solved. No more CI errors.


 
 Genuine curiosity, because maybe you have experience with that that I 
 don't: how would this work with multi-patch PRs?


I don't see how it would differ, the format is a new commit as part of 
the PR.

See: 
https://mskelton.medium.com/auto-formatting-code-using-prettier-and-github-actions-ed458f58b7df


 I ask because, personally, I don't find CI style checks to be a problem, 
 especially if there's an easy way to run a local tool to check and/or 
 fix things on a patch-by-patch basis.  That way I can make sure that the 
 code is both style-compliant and that it "reads" well for me.  OTOH I do 
 have a bit of a problem with the idea of an external system rewriting my 
 code for me, especially if the result is messy -- like a series of 
 patches that violate code style followed by an auto-generated 
 fix-the-style patch.
 
 Maybe that's too fussy ... ?  But my experience has tended to be that 
 when people entirely outsource style-compliance to external tooling, you 
 wind up with a lot of quite ugly code and harder-to-follow patches.


You've got the problem right there. There is no tool to run locally. Its 
mixed between a few different CI runner types. They are all simple 
tests, like end of line white space and all have less than desirable 
error messages that you have to track down deep in log files.

People (including myself) spend time having to figure out why the CI 
failed, rather than letting it fix any problems it encounters. It adds a 
failure mode to contributing, when we could eliminate it and have more 
consistent code as a result!
Dec 31 2022
next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Saturday, 31 December 2022 at 08:56:34 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 I don't see how it would differ, the format is a new commit as 
 part of the PR.

 See: 
 https://mskelton.medium.com/auto-formatting-code-using-prettier-and-github-actions-ed458f58b7df


OK, understood.  (It wasn't 100% clear from your previous post 
that you were envisioning one follow-up patch on top of the PR, 
as opposed to modifying patches in the PR.)


 You've got the problem right there. There is no tool to run 
 locally. Its mixed between a few different CI runner types.


Yeah, I see why that would be very painful.

What I'd like to suggest is that, regardless of what one does or 
doesn't do during CI, the absence of a single tool for checking 
or fixing style is the crux of the problem.  Whatever CI does or 
doesn't do, it's IMO useful as a developer to be able to check 
one's own code for style correctness, before submitting in a PR.

So it seems to me that the best way forward here is to make sure 
that all the wanted style checks _can_ be carried out by a single 
tool, or at least by a well defined set of tools with 
standardized configuration.

There are good examples in other languages.  I've historically 
preferred tools that just define what's objectionable rather than 
what's correct (if that makes sense), so there is still an amount 
of flexibility for the developer to write code as they wish, but 
since I discovered the Python tool 
[`black`](https://black.readthedocs.io/en/stable/), I think it's 
clear that it's at least _possible_ to craft a deterministic 
formatting tool that consistently produces good looking code.

What's particularly nice about that tool is that it can be run to 
edit code in-place, or it can be used in a dry-run mode which 
outputs a patch showing what would have been changed (with exit 
code 0 if that's nothing, or 1 if changes are required).

Where CI for my own projects is concerned, I've preferred to use 
the dry-run mode and throw it back on the PR author to actually 
_make_ the fix -- on the grounds that the PR author should be in 
control of what code changes, but also because it's 
straightforward to follow what changes are wanted, and equally 
trivial to run the tool locally to make them.  But obviously one 
could use the same tooling to append a style-fix patch to a PR, 
if that was considered desirable.


 People (including myself) spend time having to figure out why 
 the CI failed, rather than letting it fix any problems it 
 encounters. It adds a failure mode to contributing, when we 
 could eliminate it and have more consistent code as a result!


I completely agree that we want to eliminate this kind of 
uncertainty.  I just think that to achieve it we need a 
well-defined tool which can be run locally as easily as in CI.

Python tooling is particularly instructive as a good point of 
reference, because there are other tools (e.g. 
[`tox`](https://tox.wiki/en/latest/)) which make it very easy to 
run a range of different checks (style, linter, test suite, ...) 
in a standardized way, via a single command.

Of course, it's not like people haven't already tried (`dfmt` 
etc.).  It just seems to be hard to sustain the momentum to 
implement and maintain such tools for D :-(

I'll mention some of these thoughts in the feedback I plan to 
write to Mike.
Dec 31 2022
prev sibling parent Paul Backus <snarwin gmail.com> writes:
On Saturday, 31 December 2022 at 08:56:34 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 You've got the problem right there. There is no tool to run 
 locally. Its mixed between a few different CI runner types. 
 They are all simple tests, like end of line white space and all 
 have less than desirable error messages that you have to track 
 down deep in log files.


You can run the checks locally with `make -f posix.mak 
style_lint` (Phobos, druntime) or `./build.d style` (DMD).
Dec 31 2022
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/31/2022 12:36 AM, Joseph Rushton Wakeling wrote:

 But my experience has tended to be that when 
 people entirely outsource style-compliance to external tooling, you wind up
with 
 a lot of quite ugly code and harder-to-follow patches.


True enough. I adjust the style based on what the particular sequence of code
is 
doing. I doubt "good style" can be mandated. Note that D's style checker has a 
number of knobs that turn various checks off, and this is used in its checking 
of the compiler source files.
Dec 31 2022
parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Saturday, 31 December 2022 at 18:25:38 UTC, Walter Bright 
wrote:

 True enough. I adjust the style based on what the particular 
 sequence of code is doing. I doubt "good style" can be 
 mandated. Note that D's style checker has a number of knobs 
 that turn various checks off, and this is used in its checking 
 of the compiler source files.


Clearly we are in sympathy here :-)  But I've had to recognize 
that not everyone agrees, and that people have well-motivated 
reasons for wanting to try to automate the code style.  
Typically, they want to be able to put 100% focus on what the 
program is _doing_ and not have to discuss, debate, or spend time 
manually tweaking stylistic aspects.

That's caused some friction for me in the past, because I was 
very unhappy with the automated formatters that seemed to be 
available.  Finding `black` allowed me to change my mind, because 
here was a tool that deterministically generated a highly 
opinionated style (config options are limited), while still 
producing Python code that read well to my eyes.  Of course there 
are always a few edge cases, but they are _very_ limited.

If you have a spare 35 minutes and are curious, you might find it 
interesting to watch this talk by the `black` lead developer, 
which goes over some of the issues involved:
https://www.youtube.com/watch?v=nnKvBwRt72Q

That, plus trying out the tool, was enough to convince me that 
with careful enough rule design (implicitly that talk shows how 
important it is to tailor rules to the particular language 
syntax), it is possible to design deterministic formatting rules 
that are _good enough_ probably 95+% of the time -- with the 
remaining cases either tolerable, or possible to work around with 
judicious disabling of the formatter for particular code blocks.

(Dicebot told me this years ago, it's just taken this long for me 
to start believing him:-)

Of course, being possible in principle doesn't necessarily make 
it easy to do for a particular language. :-(  I have a personal 
hunch that ML-style languages like Python, Go, and Rust lend 
themselves more naturally to such auto-formatting than 
Algol-style, but that may be just my lack of experience of good 
deterministic styling tools for the latter.
Jan 01 2023
next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
When it comes to style, people are not going to be happy, no matter what 
you pick.

You don't need to put too much work into the set of rules due to this.

In our case we have declared what the style should be for the dlang/ 
repos. So... that's what the tool must do.
Jan 01 2023
parent JN <666total wp.pl> writes:
On Sunday, 1 January 2023 at 09:52:55 UTC, Richard (Rikki) Andrew 
Cattermole wrote:

 When it comes to style, people are not going to be happy, no 
 matter what you pick.

 You don't need to put too much work into the set of rules due 
 to this.

 In our case we have declared what the style should be for the 
 dlang/ repos. So... that's what the tool must do.


I've been part of some C++/Python codebases which transitioned to 
enforced clang-format/black formatting and in the end it was a 
good decision. Turned out everyone's personal code style isn't so 
precious after all and with modifying a few rules in the 
formatter you can adopt a formatting style that is acceptable for 
majority of folks. Also, every sourcecode formatter allows you to 
opt-out of auto-formatting for blocks of code, which is useful 
for manual tables and alignment.

In my personal D projects I have set dfmt to run on each source 
code file save and never really had to worry about formatting. I 
just write whatever, ctrl+S and get a nicely formatted D code. I 
may disagree with the way it formats things sometimes, but I just 
accept it as a minor tradeoff for convenience.
Jan 02 2023
prev sibling parent John Colvin <john.loughran.colvin gmail.com> writes:
On Sunday, 1 January 2023 at 08:53:58 UTC, Joseph Rushton 
Wakeling wrote:

 On Saturday, 31 December 2022 at 18:25:38 UTC, Walter Bright 
 wrote:

 True enough. I adjust the style based on what the particular 
 sequence of code is doing. I doubt "good style" can be 
 mandated. Note that D's style checker has a number of knobs 
 that turn various checks off, and this is used in its checking 
 of the compiler source files.


 Clearly we are in sympathy here :-)  But I've had to recognize 
 that not everyone agrees, and that people have well-motivated 
 reasons for wanting to try to automate the code style.  
 Typically, they want to be able to put 100% focus on what the 
 program is _doing_ and not have to discuss, debate, or spend 
 time manually tweaking stylistic aspects.


This is key. Velocity is increased by decoupling arguments about 
formatting (go complain to the autoformat authors) from progress 
on functionality.

The web of dependencies in the software development process (hard 
like "can't merge B until we merge A" and soft like "I really 
want to focus on A and not get distracted by B") is complicated 
and large and mostly hidden. Anything that slows down anything 
will slow down something else which slows down everything.

Slightly uglier code, but no PR ever waits a day on formatting 
complaints, no reviewer energy ever goes in to explaining 
formatting? It's a no-brainer.
Jan 05 2023
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/25/2022 7:57 PM, Paul Backus wrote:

 I agree that the friction cannot be reduced to zero. I still think it is 
 probably possible to reduce it to, say, 50% of its current amount, without 
 compromising on quality.


It's that people reach intractable positions, not that they're arguing about 
off-topic things.
Dec 26 2022
next sibling parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 26/12/2022 9:34 PM, Walter Bright wrote:

 On 12/25/2022 7:57 PM, Paul Backus wrote:

 I agree that the friction cannot be reduced to zero. I still think it 
 is probably possible to reduce it to, say, 50% of its current amount, 
 without compromising on quality.


 
 It's that people reach intractable positions, not that they're arguing 
 about off-topic things.


Sounds an awful lot like more compromises need to be made on the things 
people don't care about ;)

For instance: https://github.com/dlang/dmd/pull/14669

Do we really need to guarantee a compiler specific pragma has to "just 
work" on any function and not find another solution?
Dec 26 2022
prev sibling parent Paul Backus <snarwin gmail.com> writes:
On Monday, 26 December 2022 at 08:34:23 UTC, Walter Bright wrote:

 On 12/25/2022 7:57 PM, Paul Backus wrote:

 I agree that the friction cannot be reduced to zero. I still 
 think it is probably possible to reduce it to, say, 50% of its 
 current amount, without compromising on quality.


 It's that people reach intractable positions, not that they're 
 arguing about off-topic things.


In your experience, do these discussions typically end once an 
impasse has been reached, or do they continue to go in circles 
until all parties have exhausted themselves?

My impression is that many fall into the latter category. Having 
a moderator cut these fruitless arguments off at the legs would 
prevent a lot of unnecessary frustration.
Dec 26 2022
prev sibling parent monkyyy <crazymonkyyy gmail.com> writes:
On Monday, 26 December 2022 at 01:29:40 UTC, Walter Bright wrote:

 
 1. quality
 2. cost
 3. time

 Pick two.


Cost, time
Dec 26 2022
prev sibling parent areYouSureAboutThat <areYouSureAboutThat gmail.com> writes:
On Sunday, 25 December 2022 at 17:16:01 UTC, Paul Backus wrote:

 If multiple contributors with significant track records of 
 success are telling you that the frustration of working with 
 D's leadership has driven them to stop contributing, how many 
 potential contributors would you estimate have given up before 
 even getting to that point?

 D's lack of manpower is often lamented on this forum. If our 
 current approach to leadership and governance is costing us 
 manpower, that seems to me like a serious bug in the D project, 
 which we ought to prioritize fixing.


Well, to take a higher ecological viewpoint, I would suggest that 
'the priority effect' may be at play here.

i.e. the prescence of a species that arrived first, can have an 
effect on the species that arrive later.

This can often result in unbalanced, asymmetric, competitive 
interactions.

So, to my hypothesis: Competitve priority effects may be occuring 
here.
Dec 25 2022
prev sibling next sibling parent reply Max Samukha <maxsamukha gmail.com> writes:
On Saturday, 24 December 2022 at 23:22:47 UTC, ag0aep6g wrote:


 The -mv switch was added to deal with this problem, and is 
 mentioned in the comments on the issue.

 https://dlang.org/dmd-windows.html#switch-mv


 That linked documentation is buggy itself. "path/filename" is 
 missing in the syntax line. Someone should fix that, or at 
 least file an issue. Not me though.


When the specification is lacking, it is not clear what code is 
valid. In the case of -mv, the spec says (or rather implies) 
package.module=path/filename, but the implementation also allows 
package=path, which I find reasonable and rely upon. If the 
implementaion gets 'fixed' to conform to the specification, I 
will be very unhappy.
Dec 24 2022
next sibling parent peterrmaxx15 <peterrmaxx15 gmail.com> writes:
I'm hoping to see this improve, Razvan does an amazing job as PR 
manager so far which has been a real boost to getting stuff in.
Dec 30 2022
prev sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 25/12/2022 7:57 PM, Max Samukha wrote:

 When the specification is lacking, it is not clear what code is valid. 
 In the case of -mv, the spec says (or rather implies) 
 package.module=path/filename, but the implementation also allows 
 package=path, which I find reasonable and rely upon. If the 
 implementaion gets 'fixed' to conform to the specification, I will be 
 very unhappy.


Stuff like this its pretty clear that the specification is the one that 
needs fixing, not the implementation.

Do a PR, then you won't have to worry about this going forward ;)
Dec 30 2022
parent Max Samukha <maxsamukha gmail.com> writes:
On Friday, 30 December 2022 at 13:48:29 UTC, Richard (Rikki) 
Andrew Cattermole wrote:


 Do a PR, then you won't have to worry about this going forward 
 ;)


Complaining is more fun :)
Dec 31 2022
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/24/2022 3:22 PM, ag0aep6g wrote:

 For me, dealing with D's leadership has been an infuriating experience time
and 
 time again. It's the one reason why I have dialed back my contributions to
near 
 zero. There is a lot to fix in D, but when I have to fight for the privilege
of 
 cleaning up after you guys while you refuse to even recognize your own bugs, 
 that's just not worth it.


You have 28 merged pull requests:

https://github.com/dlang/dmd/pulls?q=is%3Apr+author%3Aag0aep6g+is%3Aclosed

and 2 that aren't:

https://github.com/dlang/dmd/pulls/ag0aep6g

Your track record of successful contribution is very, very good.
Dec 24 2022
prev sibling next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Saturday, 24 December 2022 at 13:46:33 UTC, Mike Parker wrote:


 I invite every member of the D community to email me at 
 social dlang.org with your specific gripes about the current 
 state of D and the things you'd like to see in the future 
 (changes, new features, etc). But don't write in general terms. 
 Be specific.


Thanks to everyone who has emailed me so far. I've received some 
long, thoughtful responses. Some of it has gone beyond the 
actionable and more into the philosophical/ideological, but 
that's welcome, too.

I hope to see more feedback in the coming days and weeks. I want 
*a lot of feedback* from several different people. Every email 
I've gotten so far has focused on different things. Some of it 
I've read before, but I need a large sample so I can identify the 
top most common gripes and wish list items.

So I'll periodically post a reminder here in the forums until I 
have enough to work with.

In the meantime, I hope everyone enjoys the holidays and has a 
safe and Happy New Year.
Dec 24 2022
parent RTM <riven baryonides.ru> writes:
On Sunday, 25 December 2022 at 05:05:33 UTC, Mike Parker wrote:

 Some of it I've read before, but I need a large sample so I can 
 identify the top most common gripes and wish list items.

 So I'll periodically post a reminder here in the forums until I 
 have enough to work with.


Probably, a deadline should be set?
Dec 24 2022
prev sibling next sibling parent reply Hipreme <msnmancini hotmail.com> writes:
On Saturday, 24 December 2022 at 13:46:33 UTC, Mike Parker wrote:

 [...]



So, the problem I have is not about what features are getting 
worked on. All the features I wanted would be implemented by now 
if we had a better decision making process. The first problem I 
see are 2: The funneling on Walter, and the insane arguing we 
have. It infinitely bothers me to see how many people has quit D. 
They didn't quit D because "oh now from the night to day I think 
I hate D so I'm quitting". It is not because the community 
itself. There was a lot of cases where we had a community 
agreement on a subject, but the heads (aka dictators) felt that 
it was bad. I understand that they can have a great impact on the 
decision, but what about when the agreement turns in a community 
consensus and the dictator's opinion is still prevailed?
Dec 25 2022
parent reply GrimMaple <grimmaple95 gmail.com> writes:
On Sunday, 25 December 2022 at 15:09:46 UTC, Hipreme wrote:

 On Saturday, 24 December 2022 at 13:46:33 UTC, Mike Parker 
 wrote:

 [...]



 So, the problem I have is not about what features are getting 
 worked on. All the features I wanted would be implemented by 
 now if we had a better decision making process. The first 
 problem I see are 2: The funneling on Walter, and the insane 
 arguing we have. It infinitely bothers me to see how many 
 people has quit D. They didn't quit D because "oh now from the 
 night to day I think I hate D so I'm quitting". It is not 
 because the community itself. There was a lot of cases where we 
 had a community agreement on a subject, but the heads (aka 
 dictators) felt that it was bad. I understand that they can 
 have a great impact on the decision, but what about when the 
 agreement turns in a community consensus and the dictator's 
 opinion is still prevailed?


I would dare to say that all the different features that being 
developed are, in fact, the main problem.

When I got into D,  live was the new hot thing, with borrow 
checkers and what not. After a year the language said "screw 
this, let's import C instead". So  live never was developed to an 
adequate quality, and borrow checker was never completed. I have 
a strong feeling that ImportC will be dropped by the time it's " 
Good enough" for dmd's internal needs, and we will be left with 
another half-baked thing that kinda works, but really doesn't.

Since the time of my rant in another thread I've spent too much 
time thinking about DLang. I frequently return to the conclusion 
that it's just doomed to sink at this point. D includes too many 
different, diametrically different, concepts, that it's 
incredibly difficult to even come to an agreement when designing 
your code. If you use one feature, you almost automatically cut 
out users that use a different feature. BetterC is the worst 
offender here, basically locking your framework to itself. 
Considering you want to make a universal framework. This is why 
phobos is so hindered at this point. You can't add anything to it 
because somebody would complain that it has to support betterC.

There definitely has to be a bigger vision about the language. Do 
you want a low level language? Do you want a higher level 
language? Do you just want C but better?
But, at that point, you can only break the language. There's no 
fixing that.
Dec 25 2022
next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 26/12/2022 4:54 AM, GrimMaple wrote:

 BetterC is the worst offender here, basically locking your framework to 
 itself. Considering you want to make a universal framework. This is why 
 phobos is so hindered at this point. You can't add anything to it 
 because somebody would complain that it has to support betterC.


That is entirely incorrectly.

Nobody expects things to work in -betterC in Phobos. The only exception 
to that rule are things like std.traits which only operate at CTFE and 
should have no differing behavior based upon what flags are passed.

We can't add things to Phobos because of leadership. In the last 10 
years we have only added allocators and loggers to experimental, and 
only one of them was complete enough to come out of experimental. It has 
nothing at all to do with some flag why we can't put things in. It has 
always been a nightmare.
Dec 25 2022
parent reply Dukc <ajieskola gmail.com> writes:
On Sunday, 25 December 2022 at 18:16:59 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 We can't add things to Phobos because of leadership. In the 
 last 10 years we have only added allocators and loggers to 
 experimental, and only one of them was complete enough to come 
 out of experimental. It has nothing at all to do with some flag 
 why we can't put things in. It has always been a nightmare.


I guess that's true if you're adding an entire module. When 
adding an individual function, or a new overload of existing one, 
in my experience the issue main issue is the amount and length of 
review cycles. It's better now than a few years ago thanks to the 
PR managers.
Jan 02 2023
parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 03/01/2023 12:25 PM, Dukc wrote:

 On Sunday, 25 December 2022 at 18:16:59 UTC, Richard (Rikki) Andrew 
 Cattermole wrote:

 We can't add things to Phobos because of leadership. In the last 10 
 years we have only added allocators and loggers to experimental, and 
 only one of them was complete enough to come out of experimental. It 
 has nothing at all to do with some flag why we can't put things in. It 
 has always been a nightmare.


 
 I guess that's true if you're adding an entire module. When adding an 
 individual function, or a new overload of existing one, in my experience 
 the issue main issue is the amount and length of review cycles. It's 
 better now than a few years ago thanks to the PR managers.


Yes absolutely.

Razvan has been doing an amazing job! I do hope he gets to become fully 
paid up full time at some point, because he does bring to the table a 
lot of process improvements.

The problem now is a much higher level one, medium to long term, rather 
than short term. For Phobos anyway.
Jan 02 2023
prev sibling parent Kagamin <spam here.lot> writes:
On Sunday, 25 December 2022 at 15:54:01 UTC, GrimMaple wrote:

 There definitely has to be a bigger vision about the language. 
 Do you want a low level language? Do you want a higher level 
 language? Do you just want C but better?


I use D as all three and it works better than other languages. 
The end of Moore law means you can't spam people with Electron 
applications, which makes writing efficient programs in high 
level language a good goal. Currently only D realistically does 
it, and maybe Nim.
Mar 21 2023
prev sibling next sibling parent John Colvin <john.loughran.colvin gmail.com> writes:
On Saturday, 24 December 2022 at 13:46:33 UTC, Mike Parker wrote:

 Everyone in the D community has their own reasons for being 
 here. We each have our own goals and plans, our own likes and 
 dislikes, our own expectations and tolerance levels when those 
 expectations go unmet, and so on.

 [...]


Referring back to my post a month ago: 
https://forum.dlang.org/post/xamclovgxzzrjzntengl forum.dlang.org

An eidetic memory is not required, this is all stuff that 
everyone with long-term D experience has seared in to their 
brains.
Jan 01 2023
prev sibling parent Dukc <ajieskola gmail.com> writes:
On Saturday, 24 December 2022 at 13:46:33 UTC, Mike Parker wrote:

 I invite every member of the D community to email me at 
 social dlang.org with your specific gripes about the current 
 state of D and the things you'd like to see in the future 
 (changes, new features, etc). But don't write in general terms. 
 Be specific.


Okay, sent my list. A noteworthy thing IMO is that I could not 
think of any one big issue in the language or the standard 
library itself. I submitted six points of which one of them was 
about tooling. All of the remainder were some sort of social or 
policy issues.
Jan 02 2023