www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The forked elephant in the room

reply Atila Neves <atila.neves gmail.com> writes:
As seen on this very same forum / mailing list, some of the 
members of
the community have decided to fork D over disagreements with how
things are being run.

D is an open source project, and as such in a way meant to be
forked. The D leadership does not endorse the fork, but we also 
do not
bemoan the people who are involved. We think it is unfortunate 
that
our scant resources are going to be split, but we acknowledge 
that we
have as much control over that as we usually do getting 
contributors
to work on what we think is important.

I personally am going to continue working on a spec [1] for Adam
Ruppe's work [2] on string interpolation. I think he has done 
great
work and see no reason to not make a D a better language because 
of
this fork. It was in great part due to his objections to DIP1027 
that
it did not get accepted and his insight on the feature have been
invaluable.

In 2023, we took our first steps on a long road to regorganising 
our
processes. We're continuing on that path in 2024 and expect to 
pick up
momentum as the year progresses.

We hope that in time the contributors to OpenD will decide to lend
their time instead to the D language.


[1] 
https://github.com/atilaneves/DIPs/blob/string-interpolation/Interpolation.md
[2] https://github.com/dlang/dmd/pull/15715
Jan 15
next sibling parent reply IGotD- <nise nise.com> writes:
On Monday, 15 January 2024 at 09:46:11 UTC, Atila Neves wrote:

 I personally am going to continue working on a spec [1] for Adam
 Ruppe's work [2] on string interpolation. I think he has done 
 great
 work and see no reason to not make a D a better language 
 because of
 this fork. It was in great part due to his objections to 
 DIP1027 that
 it did not get accepted and his insight on the feature have been
 invaluable.


 We hope that in time the contributors to OpenD will decide to 
 lend
 their time instead to the D language.


Is there no bottom how low you can go? This is like a manager who 
gives a former a employee an astronomical raise after giving the 
notice and the new job is waiting. At that point the manager can 
give you any amount because it doesn't mean anything, the manager 
just do it in order to mess with the mind of the former employee.

Also if you believe that the fork was made just because 
disagreement about DIP1036 and DIP 1027 you are mistaken. The 
dissatisfaction with the D management and how the project is run 
has been growing for several years if not over a decade. It is 
rather surprising that a serious fork wasn't made earlier.

If you think that stopping the fork is going to help, think 
again. The behaviour of the D management is endemic and cannot be 
changed because much is linked to your personalities, much to the 
personally of Walter. For me the desire to remove binary literals 
was the wakeup call for me that something is not quite right and 
it cannot be fixed.

Now I cannot stop the D project to include things from openD and 
vice versa and I see no problems with that. However, trying to 
infiltrate the openD in order to derail it or influence it is 
benign and will lead to missed opportunities.

If you have left over work from before the fork, get it done. 
After that, good bye!
Jan 15
next sibling parent reply Curious Observer <c.o mail.com> writes:
On Monday, 15 January 2024 at 10:11:33 UTC, IGotD- wrote:

 Also if you believe that the fork was made just because 
 disagreement about DIP1036 and DIP1027 you are mistaken.


While having looked at the arguments on both sides, as the name 
suggests I don't have any skin in this game. How ever having read 
the arguments for DIP1036 and DIP1027 the difference do seem 
chalk and cheese.

The fact these obvious differences seem to blind so many is 
rather amazing.

I'm not qualified to respond on the merits of either design, 
however, as a long time C and C++ developer I always saw the 
benefit of the %s approach.

However, unfortunately as a Windows C and C++ developer some 15 



Move on a few more years, even a hard core %s sprintf guy like 

C++ with it's crazy cout rules got it totally wrong.

My two cents.
Jan 15
parent Curious Observer <c.o mail.com> writes:
On Monday, 15 January 2024 at 10:54:06 UTC, Curious Observer 
wrote:
And of course, if the language can't provide protection against 
SQL injection, then at least don't become remember as just 
another PHP.

"While we have explored the prevalence of XSS CWEs in depth, PHP 
is the only language with prominent SQL Injection (CWE-89) 
vulnerabilities [7]"

https://www.scirp.org/journal/paperinformation?paperid=128108#:~:text=While%20we%20have%20explored%20the,2021%20by%20language%20and%20type.
Jan 15
prev sibling next sibling parent reply Meta <jared771 gmail.com> writes:
On Monday, 15 January 2024 at 10:11:33 UTC, IGotD- wrote:

 Is there no bottom how low you can go?
 [snip]

 If you think that stopping the fork is going to help, think 
 again.
 [snip]

 However, trying to infiltrate the openD in order to derail it 
 or influence it...


How does your mind invent such bad intentions from a diplomatic 
and well-meaning attempt to address a political charged issue? 
Your post is completely unhinged.
Jan 15
parent reply IGotD- <nise nise.com> writes:
On Monday, 15 January 2024 at 15:20:08 UTC, Meta wrote:

 How does your mind invent such bad intentions from a diplomatic 
 and well-meaning attempt to address a political charged issue? 
 Your post is completely unhinged.


I see it as the intentions are benign. The point of the fork was 
to get away from the D project management and I see the post as 
an attempt to get a foot into the fork to destabilize it.

I also want to point out that the intention is not to deter 
anyone who are not in D project management to use openD and 
contribute. However, if you are on the D project management if 
you try to get involved in the openD project I'm highly skeptical 
about your intentions.

The D project should instead welcome the addition to the fork in 
order revitalize the language and create healthy competition.
Jan 15
parent "H. S. Teoh" <hsteoh qfbox.info> writes:
On Mon, Jan 15, 2024 at 03:36:52PM +0000, IGotD- via Digitalmars-d wrote:
[...]

 I also want to point out that the intention is not to deter anyone who
 are not in D project management to use openD and contribute. However,
 if you are on the D project management if you try to get involved in
 the openD project I'm highly skeptical about your intentions.


On the contrary, Adam himself has said that if the current upstream
management people would like to contribute to openD, he'd have seats
reserved for them at the table.  Though he is not holding his breath for
this to happen.



 The D project should instead welcome the addition to the fork in order
 revitalize the language and create healthy competition.


Given the acrimony surrounding the decision to fork, I don't think this
is a very realistic expectation.


T

-- 
Guns don't kill people. Bullets do.
Jan 15
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Mon, Jan 15, 2024 at 10:11:33AM +0000, IGotD- via Digitalmars-d wrote:
[...]

 Also if you believe that the fork was made just because disagreement
 about DIP1036 and DIP 1027 you are mistaken. The dissatisfaction with
 the D management and how the project is run has been growing for
 several years if not over a decade. It is rather surprising that a
 serious fork wasn't made earlier.


This is true, we have been repeating over the last decade or so the
pattern of attracting enthusiastic contributors due to the technical
excellence of D, only to have them turn around and leave after coming to
an impasse with the project's management.  As I have said previously,
the problem isn't so much that things did not go their way; I think any
reasonable person would understand that in technical decisions there's
always pros and cons and one could go either way, and that whichever way
a decision goes, it would work out, one could live with it.

No, the root of the problem is social, not technical. The thing is, the
overall impression a contributor gets is:

1) They have little or no say over key project decisions.

2) There are unwritten requirements that are not communicated
beforehand, but may suddenly appear at any time and land on you like a
pile of bricks, negating weeks or even months of hard work and effort.

3) Preferred solutions will go through by default, and to reverse them
is a long uphill battle.

4) Non-preferred solutions are not even considered by default, and to
get them considered at all is an equally long uphill battle, not to
mention an even longer uphill battle to get them approved.

5) Mistakes in preferred solutions in retrospect will generally not be
acknowledged, or papered over with convenient excuses, while similar
mistakes in non-preferred solutions will result in a ton of bricks
landing on its proponents.

6) Preferred solutions may cut corners in the approval process, but
non-preferred solutions must fulfill every last detail of a bureaucratic
process to the letter even for the most trivial of decisions, otherwise
they will be duly ignored.


These impressions are not necessarily accurate, of course. But they do
seem very real from the POV of would-be contributors, and can be very
demotivating. As long as they are not addressed, D is going to continue
experiencing manpower issues.

Again, this has nothing to do with technical merit; it's a social
problem.  A programming language project involves not only technical
issues, but social issues, because it has to be run by humans. Technical
excellence can only go so far before a contributor decides it's not
worth dealing with the social issues.

Unfortunately, it does not seem that this is going to change as long as
the current project management continues in its present course.  So it's
unlikely that it will ever be addressed.



 If you think that stopping the fork is going to help, think again. The
 behaviour of the D management is endemic and cannot be changed because
 much is linked to your personalities, much to the personally of
 Walter. For me the desire to remove binary literals was the wakeup
 call for me that something is not quite right and it cannot be fixed.


Now this is uncalled for. Where in Atila's post was anything mentioned
about stopping the fork?



 Now I cannot stop the D project to include things from openD and vice
 versa and I see no problems with that. However, trying to infiltrate
 the openD in order to derail it or influence it is benign and will
 lead to missed opportunities.


[...]

This is also uncalled for. Where in Atila's post is there anything to do
with infiltration?


T

-- 
A programming language should be a toolbox for the programmer to draw
upon, not a minefield of dangerous explosives that you have to very
carefully avoid touching in the wrong way.
Jan 15
next sibling parent tony <tonytdominguez aol.com> writes:
On Monday, 15 January 2024 at 18:33:07 UTC, H. S. Teoh wrote:


 Now this is uncalled for.
 This is also uncalled for.


I think the worst part of the post was clearly:

"Is there no bottom how low you can go?"
Jan 15
prev sibling next sibling parent reply IGotD- <nise nise.com> writes:
On Monday, 15 January 2024 at 18:33:07 UTC, H. S. Teoh wrote:

 Now this is uncalled for. Where in Atila's post was anything 
 mentioned about stopping the fork?


This.


 We hope that in time the contributors to OpenD will decide to 
 lend
 their time instead to the D language.


He basically writes "We don't want you to work on openD project, 
you should work on the D project". The key word here is *instead* 
which suggest that it should be mutually exclusive.


 This is also uncalled for. Where in Atila's post is there 
 anything to do with infiltration?


I'm concerned that the D management will influence the openD 
project and try to bring in the "old ways" which is the state of 
this project right now. It can also creep in when everybody is 
totally unaware of it, like a spouse always ending up in abusive 
relationships. I suggest that the decision making in openD should 
be isolated from the old D project management, at least in the 
beginning until openD has matured.
Jan 15
next sibling parent Elias (0xEAB) <desisma heidel.beer> writes:
On Monday, 15 January 2024 at 19:10:27 UTC, IGotD- wrote:

 He basically writes "We don't want you to work on openD The key 
 word here is *instead* which suggest that it should be mutually 
 exclusive.


Why so sure about that? Why isn’t the keyword *hope*?
Jan 15
prev sibling next sibling parent claptrap <clap trap.com> writes:
On Monday, 15 January 2024 at 19:10:27 UTC, IGotD- wrote:

 On Monday, 15 January 2024 at 18:33:07 UTC, H. S. Teoh wrote:

 Now this is uncalled for. Where in Atila's post was anything 
 mentioned about stopping the fork?


 This.


 We hope that in time the contributors to OpenD will decide to 
 lend
 their time instead to the D language.


 He basically writes "We don't want you to work on openD 
 project, you should work on the D project". The key word here 
 is *instead* which suggest that it should be mutually exclusive.


Maybe you read to much into it. Maybe he just hopes the egg can 
be unscrambled at some point in the future.

But even if that's not what he meant so what? It's quite 
reasonable to believe that the fork will be detrimental to D, and 
if you really believe that then it would be perfectly rational to 
hope that it fizzles out and people come back into mainline. Im 
not saying that is what he thinks, but there's a perfectly 
rational and inoffensive reason to hold that view.



 This is also uncalled for. Where in Atila's post is there 
 anything to do with infiltration?


 I'm concerned that the D management will influence the openD 
 project and try to bring in the "old ways" which is the state 
 of this project right now. It can also creep in when everybody 
 is totally unaware of it, like a spouse always ending up in 
 abusive relationships. I suggest that the decision making in 
 openD should be isolated from the old D project management, at 
 least in the beginning until openD has matured.


What like their gonna send their agents over to derail OpenD? You 
know it'll need a DIP, a couple of years arguing in the forum, 
when somebody eventually completes the work it wont be merged for 
some reason. Etc.. I make that 4 years at least before you need 
to worry.

If you're smoking weed stop, if your not smoking weed start.
Jan 15
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/15/2024 11:10 AM, IGotD- wrote:

 I'm concerned that the D management will influence the openD project


D is designed with being forkable in mind. Anyone is free to fork it for any 
reason. D's license is the most open license in the industry, and I'm proud of
that.

In the spirit of that, I won't be interfering with anybody's forks. I made no 
attempt to interfere with Tango, Amber, nor any other forks.

I ask for the reciprocal courtesy from the openD folks.
Jan 15
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/15/2024 10:33 AM, H. S. Teoh wrote:

 Preferred solutions [...]


What mechanism would you propose?

I can't help but think a preferred solution already has a lot of buy-in for it, 
and so needs less justification?

For a less preferred solution, it needs to make a compelling case for it.

Before investing a lot of time making a proposal and/or coding up an 
implementation, I strongly recommend hashing the idea out in the n.g. first,
and 
seeing if there's buy-in to the concept.

I've floated many ideas on the n.g. in this manner. Some went ahead, some went 
into the dumpster and I'm glad I didn't waste time on the latter. For two
recent 
examples, see the threads entitled:

"Tuples, CTFE and Sliding Template Arguments"

"Warn about using the GC"

BTW, has anyone else tried to get changes into another language? I have. It's a 
years long process, and is extremely difficult to get it through. You have a 
better chance also if you're willing to fly to the conference meetings. None of 
my proposals got anywhere. Ironically, they way they made it in was to do them
in D!

P.S. We also have some contributors who have a long track record of superb 
contributions. They also have a consistent commitment to promptly fixing 
anything that goes wrong with it down the road. Yes, they get a lot less 
scrutiny. They've earned it.
Jan 15
parent reply GrimMaple <grimmaple95 gmail.com> writes:
On Monday, 15 January 2024 at 23:33:23 UTC, Walter Bright wrote:

 BTW, has anyone else tried to get changes into another 
 language? I have. It's a years long process, and is extremely 
 difficult to get it through.


Just because it's bad somewhere else doesn't justify leaving 
things as is here


 P.S. We also have some contributors who have a long track 
 record of superb contributions. They also have a consistent 
 commitment to promptly fixing anything that goes wrong with it 
 down the road. Yes, they get a lot less scrutiny. They've 
 earned it.


Care to give a few names?


 In the spirit of that, I won't be interfering with anybody's 
 forks. I made no attempt to interfere with Tango, Amber, nor 
 any other forks.


Did that work out well for you, or D, in the end? It's very 
interesting how you often use "lack of manpower" as an excuse to 
not get things done, yet you are more than willing to just let 
this "manpower" go without even an iota of interest or any 
attempts to make peace


 I can't help but think a preferred solution already has a lot 
 of buy-in for it, and so needs less justification?


It's not the need of justification that people hate, it's the 
fact that you stop useful contributions based on some 
bike-shedding level issue, whilst allowing yourself to push 
fundamentally flawed features (ImportC for instance). If you 
showed the same level of concern for your own features -- there 
wouldn't be so much backlash. Instead, you can't even be bothered 
to __read__ the string interpolation that works well. And, on the 
other hand, you push in  live (that doesn't work), ImportC (that 
doesn't work), and the list goes on.

I know that you like to say on hackernews that "D has ownership" 
and "D can ImportC", but I'm sorry, it only has ownership in an 
isolated dmd test suite, and it all works really poorly in the 
real world. Same goes for ImportC. If you can't compile 99% of C 
code (I'll give you 95%, fine) it's useless in practice.
Jan 15
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/15/2024 4:14 PM, GrimMaple wrote:

 you are 
 more than willing to just let this "manpower" go without even an iota of 
 interest or any attempts to make peace


A couple days ago, you complained in the n.g. that a new deprecation introduced 
in the latest release broke your code. I replied asking for more information on 
it, so I could address it.

You did not reply.
Jan 15
prev sibling next sibling parent reply Mike Shah <mshah.475 gmail.com> writes:
On Tuesday, 16 January 2024 at 00:14:50 UTC, GrimMaple wrote:

 On Monday, 15 January 2024 at 23:33:23 UTC, Walter Bright wrote:

 BTW, has anyone else tried to get changes into another 
 language? I have. It's a years long process, and is extremely 
 difficult to get it through.


 Just because it's bad somewhere else doesn't justify leaving 
 things as is here


 P.S. We also have some contributors who have a long track 
 record of superb contributions. They also have a consistent 
 commitment to promptly fixing anything that goes wrong with it 
 down the road. Yes, they get a lot less scrutiny. They've 
 earned it.


 Care to give a few names?


 In the spirit of that, I won't be interfering with anybody's 
 forks. I made no attempt to interfere with Tango, Amber, nor 
 any other forks.


 Did that work out well for you, or D, in the end? It's very 
 interesting how you often use "lack of manpower" as an excuse 
 to not get things done, yet you are more than willing to just 
 let this "manpower" go without even an iota of interest or any 
 attempts to make peace


 I can't help but think a preferred solution already has a lot 
 of buy-in for it, and so needs less justification?


 It's not the need of justification that people hate, it's the 
 fact that you stop useful contributions based on some 
 bike-shedding level issue, whilst allowing yourself to push 
 fundamentally flawed features (ImportC for instance). If you 
 showed the same level of concern for your own features -- there 
 wouldn't be so much backlash. Instead, you can't even be 
 bothered to __read__ the string interpolation that works well. 
 And, on the other hand, you push in  live (that doesn't work), 
 ImportC (that doesn't work), and the list goes on.

 I know that you like to say on hackernews that "D has 
 ownership" and "D can ImportC", but I'm sorry, it only has 
 ownership in an isolated dmd test suite, and it all works 
 really poorly in the real world. Same goes for ImportC. If you 
 can't compile 99% of C code (I'll give you 95%, fine) it's 
 useless in practice.


There's been some proposals I've seen that have taken 10+ years 
(std::mdspan) in C++ to get in. Reasons can be for backwards 
compatibility, ease of implementation, need in the language 
versus simply a library feature, not understanding the feature, 
etc. Sometimes it's just a climate change in programming -- so 
many more folks leaning into features common in functional 
languages now as an example!

I think the C++ committee process is also evolving over time. 
Though they have the same (sometimes intense) debates I've 
observed here and other communities in regards to features.

I personally think importC is a very important feature for the 
language and it's growth/adoption.  live I haven't used much, but 
I like that it's there and hope it continues developing.

Getting back to the original topic -- I appreciated reading 
Atila's response --thanks Atila! Hoping for the best for all 
projects, I'll contribute where I can!
Jan 15
next sibling parent reply claptrap <clap trap.com> writes:
On Tuesday, 16 January 2024 at 01:11:16 UTC, Mike Shah wrote:

 On Tuesday, 16 January 2024 at 00:14:50 UTC, GrimMaple wrote:


 I think the C++ committee process is also evolving over time. 
 Though they have the same (sometimes intense) debates I've 
 observed here and other communities in regards to features.


yeah but D pretty much only has to get Walter and Atila to agree 
on it. It's not like there's vast amount of stakeholders, or 
committee members that you need to get on board like with C++.

It should actually be an advantage for D but somehow its not.



 Jan 15



  parent reply Mike Shah <mshah.475 gmail.com>  writes:


On Tuesday, 16 January 2024 at 01:37:40 UTC, claptrap wrote:

 On Tuesday, 16 January 2024 at 01:11:16 UTC, Mike Shah wrote:

 On Tuesday, 16 January 2024 at 00:14:50 UTC, GrimMaple wrote:


 I think the C++ committee process is also evolving over time. 
 Though they have the same (sometimes intense) debates I've 
 observed here and other communities in regards to features.


 yeah but D pretty much only has to get Walter and Atila to 
 agree on it. It's not like there's vast amount of stakeholders, 
 or committee members that you need to get on board like with 
 C++.

 It should actually be an advantage for D but somehow its not.


Pros and cons I imagine to that that, though I'm not trying to 
push any DIPs,

I think we also need to think about how to grow the team and get 
them more help. Many other language foundations have money behind 
them to back a few full-time developers. I'll do what I can on 
advocacy around D, because I think it's a wonderful language and 
community -- that's why we're all here! :)



 Jan 15



  parent  aberba <karabutaworld gmail.com>  writes:


On Tuesday, 16 January 2024 at 02:33:32 UTC, Mike Shah wrote:

 On Tuesday, 16 January 2024 at 01:37:40 UTC, claptrap wrote:

 On Tuesday, 16 January 2024 at 01:11:16 UTC, Mike Shah wrote:

 [...]


 yeah but D pretty much only has to get Walter and Atila to 
 agree on it. It's not like there's vast amount of 
 stakeholders, or committee members that you need to get on 
 board like with C++.

 It should actually be an advantage for D but somehow its not.


 Pros and cons I imagine to that that, though I'm not trying to 
 push any DIPs,

 I think we also need to think about how to grow the team and 
 get them more help. Many other language foundations have money 
 behind them to back a few full-time developers.


And it didn't fly down from the sky. Donors are humans too so 
without a social side to D management, your aren't getting much 
financial support either. Most open source projects (Gnome, 
Linux, Rust, PHP, Node.js, Gimp, Inkscape, Krita, ...)  have ways 
to draw support and funding. We only have niche Dconf which has 
only been about code, the other equally important part of any 
foundation is severely lacking.


I'll do what I

 can on advocacy around D, because I think it's a wonderful 
 language and community -- that's why we're all here! :)


👍



 Jan 16



prev sibling  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 1/15/2024 5:11 PM, Mike Shah wrote:

 Getting back to the original topic -- I appreciated reading Atila's response 
 --thanks Atila! Hoping for the best for all projects, I'll contribute where I
can!


Can I pester you again for your amazing threading library?



 Jan 15



  parent reply Mike Shah <mshah.475 gmail.com>  writes:


On Tuesday, 16 January 2024 at 01:46:10 UTC, Walter Bright wrote:

 On 1/15/2024 5:11 PM, Mike Shah wrote:

 Getting back to the original topic -- I appreciated reading 
 Atila's response --thanks Atila! Hoping for the best for all 
 projects, I'll contribute where I can!


 Can I pester you again for your amazing threading library?


That might be Roy Margalit you are thinking of? Or maybe it was 
Sebastiaan Koppe's talk on Structured Concurrency?  :)

(As an aside, my Ph.D. work was in Java doing some concurrency 
studies on performance -- so eventually I'd like to do more 
research work in D on this topic)



 Jan 15



 next sibling parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 1/15/2024 6:25 PM, Mike Shah wrote:

 On Tuesday, 16 January 2024 at 01:46:10 UTC, Walter Bright wrote:

 On 1/15/2024 5:11 PM, Mike Shah wrote:

 Getting back to the original topic -- I appreciated reading Atila's response 
 --thanks Atila! Hoping for the best for all projects, I'll contribute where I 
 can!


 Can I pester you again for your amazing threading library?


 
 That might be Roy Margalit you are thinking of? Or maybe it was Sebastiaan 
 Koppe's talk on Structured Concurrency?  :)


Ah, maybe you're right!



 (As an aside, my Ph.D. work was in Java doing some concurrency studies on 
 performance -- so eventually I'd like to do more research work in D on this
topic)


That would be something to look forward too!



 Jan 15



prev sibling  parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz>  writes:


On 16/01/2024 3:25 PM, Mike Shah wrote:

 (As an aside, my Ph.D. work was in Java doing some concurrency studies 
 on performance -- so eventually I'd like to do more research work in D 
 on this topic)


If you would like a suggestion on this topic, may I suggest coroutines?

 From what I've seen in my library implementation they are the right way 
to do asynchronous coding and they are at the fore-front of concurrency 
research.

What is very interesting is that in D, as long as a function is being 
compiled the compiler could slice and dice it into a coroutine object 
(such as a closure) without needing to be annotated as such explicitly.

It could be done implicitly upon the library struct that represents the 
language coroutine constructor.

No async/await, no writing for asynchronously, just sequentially.

For these reasons I've told Adam Wilson that if I am to be involved with 
an event loop library for PhobosV3, I would not consider it without such 
a feature. Because the alternatives are either a hacked together 
workaround that is fail heavy (fibers), or rather involved in how you 
need to write (callbacks).

https://github.com/Project-Sidero/eventloop/blob/master/source/sidero/eventloop/coroutine/builder.d#L213

Lastly, what I call a future completion (a specific coroutine) is 
probably one of my most genius ideas of all time. It allows things like 
socket read to return a coroutine that will be triggered in say async 
read mechanism, but work with the coroutine worker runner dependency 
analysis.

https://github.com/Project-Sidero/eventloop/blob/master/source/sidero/eventloop/tasks/future_completion.d#L113



 Jan 15



 next sibling parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 1/15/2024 10:38 PM, Richard (Rikki) Andrew Cattermole wrote:

 [...]


This sounds cool. Please do a DConf presentation on it!



 Jan 16



  parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz>  writes:


On 16/01/2024 9:08 PM, Walter Bright wrote:

 On 1/15/2024 10:38 PM, Richard (Rikki) Andrew Cattermole wrote:

 [...]


 This sounds cool. Please do a DConf presentation on it!


I've talked about this on BeerConf, but there are a few reasons why 
unless DConf is here in New Zealand, its probably best that I don't go.

However on that topic, I was going to do a Unicode talk for DConf Online 
this year, but alas that kinda depended upon UAX31 identifiers, and you 
haven't been too keen to approve that line of work so I haven't done it.

Anyway regarding my stuff, a lot of the lessons learned from it have 
gone into other work like PhobosV3 and Paul's work on allocators. Its 
going to show up at DConf at some point I expect.

Now if only I could convince you about having reference counting... 
that's another lesson that came from it. Good chance I'm going to have 
to drop DIP1000/scope if that cross behavior isn't resolved tbh. I can 
bare the pain, but I can't ask others to.



 Jan 16



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 1/16/2024 12:23 AM, Richard (Rikki) Andrew Cattermole wrote:

 However on that topic, I was going to do a Unicode talk for DConf Online this 
 year, but alas that kinda depended upon UAX31 identifiers, and you haven't
been 
 too keen to approve that line of work so I haven't done it.


I have actually approved it. My mistake it was not properly communicated to you.



 Anyway regarding my stuff, a lot of the lessons learned from it have gone into 
 other work like PhobosV3 and Paul's work on allocators. Its going to show up
at 
 DConf at some point I expect.


Good


 Now if only I could convince you about having reference counting... that's 
 another lesson that came from it. Good chance I'm going to have to drop 
 DIP1000/scope if that cross behavior isn't resolved tbh. I can bare the pain, 
 but I can't ask others to.


We've investigated ref counting several times, but never figured out a way to 
make it both efficient and memory safe.



 Jan 16



  parent  "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz>  writes:


On 17/01/2024 8:50 AM, Walter Bright wrote:

 On 1/16/2024 12:23 AM, Richard (Rikki) Andrew Cattermole wrote:

 However on that topic, I was going to do a Unicode talk for DConf 
 Online this year, but alas that kinda depended upon UAX31 identifiers, 
 and you haven't been too keen to approve that line of work so I 
 haven't done it.


 
 I have actually approved it. My mistake it was not properly communicated 
 to you.


The updated plan was not as you never replied. The earlier plan of 
removing non-starters was (but that is a breaking change and strategy 
surrounding that changed before I could implement it fully).

https://github.com/dlang/dmd/pull/15307#issuecomment-1620636247

I'm double checking that we are meaning the same thing. Regardless, 
breaking change prevention means I need to check in with you about how 
to move forward.


 Now if only I could convince you about having reference counting... 
 that's another lesson that came from it. Good chance I'm going to have 
 to drop DIP1000/scope if that cross behavior isn't resolved tbh. I can 
 bare the pain, but I can't ask others to.


 
 We've investigated ref counting several times, but never figured out a 
 way to make it both efficient and memory safe.


That is not our job.

Efficiency is a problem for the backend to deal with (LLVM/GCC only). 
Doing it with copy constructors and destructors removes all possibility 
of ever optimizing it. They can't be elided, nor be communicated to the 
backend that this is what they are.

Such backends have the capability for other languages like Objective-C. 
We'd need to figure out how to tap into it, but it is there in some form.

Regardless it won't be any worse than what we have now. The only 
difference being is that we'll be able to encode that it is a lifetime 
mechanic in the type system allowing it to override scope and hopefully 
be key to helping get D classes working in -betterC (decoupling it from 
druntime is something I want to look into).



 Jan 16



prev sibling  parent reply ikod <igor.khasilev gmail.com>  writes:


Hello,


On Tuesday, 16 January 2024 at 06:38:16 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 On 16/01/2024 3:25 PM, Mike Shah wrote:

 (As an aside, my Ph.D. work was in Java doing some concurrency 
 studies on performance -- so eventually I'd like to do more 
 research work in D on this topic)





 What is very interesting is that in D, as long as a function is 
 being compiled the compiler could slice and dice it into a 
 coroutine object (such as a closure) without needing to be 
 annotated as such explicitly.


In Rust compiler convert `async` code into state machine with 
context.


 It could be done implicitly upon the library struct that 
 represents the language coroutine constructor.

 No async/await, no writing for asynchronously, just 
 sequentially.


I'd start from defining event loop API to decouple interface from 
implementations.



 Jan 16



  parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz>  writes:


On 16/01/2024 10:54 PM, ikod wrote:

 Hello,
 
 
 On Tuesday, 16 January 2024 at 06:38:16 UTC, Richard (Rikki) Andrew 
 Cattermole wrote:

 On 16/01/2024 3:25 PM, Mike Shah wrote:

 (As an aside, my Ph.D. work was in Java doing some concurrency 
 studies on performance -- so eventually I'd like to do more research 
 work in D on this topic)




 

 What is very interesting is that in D, as long as a function is being 
 compiled the compiler could slice and dice it into a coroutine object 
 (such as a closure) without needing to be annotated as such explicitly.


 
 In Rust compiler convert `async` code into state machine with context.


Yeah that is basically what a coroutine becomes.


 It could be done implicitly upon the library struct that represents 
 the language coroutine constructor.

 No async/await, no writing for asynchronously, just sequentially.


 
 I'd start from defining event loop API to decouple interface from 
 implementations.


I have done this in the past. You end up defining the user experience in 
the process.

Unless you go out of your way with something like coroutines, or fibers, 
you're pretty much stuck with callbacks of some kind and that is not 
going to fly.



 Jan 16



  parent reply ikod <igor.khasilev gmail.com>  writes:


On Tuesday, 16 January 2024 at 10:13:15 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 I'd start from defining event loop API to decouple interface 
 from implementations.


 I have done this in the past. You end up defining the user 
 experience in the process.

 Unless you go out of your way with something like coroutines, 
 or fibers, you're pretty much stuck with callbacks of some kind 
 and that is not going to fly.


I had no problems implementing a common API for select, poll, 
epoll, kqueue event loops (never tried Linux io-uring or Windows 
completion ports). This API can be declared and used for 
independent implementations of current and future OS event 
systems.

On top of this implementations for tasks, timeouts, and so on can 
be created.

Are there any reasons why this won't work?



 Jan 16



  parent  "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz>  writes:


On 17/01/2024 3:42 AM, ikod wrote:

 On Tuesday, 16 January 2024 at 10:13:15 UTC, Richard (Rikki) Andrew 
 Cattermole wrote:

 I'd start from defining event loop API to decouple interface from 
 implementations.


 I have done this in the past. You end up defining the user experience 
 in the process.

 Unless you go out of your way with something like coroutines, or 
 fibers, you're pretty much stuck with callbacks of some kind and that 
 is not going to fly.


 
 I had no problems implementing a common API for select, poll, epoll, 
 kqueue event loops (never tried Linux io-uring or Windows completion 
 ports). This API can be declared and used for independent 
 implementations of current and future OS event systems.
 
 On top of this implementations for tasks, timeouts, and so on can be 
 created.
 
 Are there any reasons why this won't work?


You may have misunderstood me.

I suggested to design the user experience first, and only then build the 
event loop itself to fulfill its needs.

Anything other than that, will produce undesirable user experience 
because you did not intentionally design it. It was shoehorned on to the 
implementation of the event loop (which is the wrong way round).



 Jan 16



prev sibling  parent reply Dibyendu Majumdar <d.majumdar gmail.com>  writes:


On Tuesday, 16 January 2024 at 00:14:50 UTC, GrimMaple wrote:

 P.S. We also have some contributors who have a long track 
 record of superb contributions. They also have a consistent 
 commitment to promptly fixing anything that goes wrong with it 
 down the road. Yes, they get a lot less scrutiny. They've 
 earned it.


 Care to give a few names?


What is your contribution to D?

As Walter says forks are good. But please go work on your fork 
and make it great, rather than complaining here.

If OpenD is good, it will be good competition to D and help spur 
things. But on the other hand, it requires full time dedicated & 
knowledgeable people to maintain a language, so it remains to be 
seen whether anything comes out of the fork.



 Jan 16



  parent  Hors <q q.com>  writes:


On Tuesday, 16 January 2024 at 10:33:13 UTC, Dibyendu Majumdar 
wrote:

 On Tuesday, 16 January 2024 at 00:14:50 UTC, GrimMaple wrote:

 P.S. We also have some contributors who have a long track 
 record of superb contributions. They also have a consistent 
 commitment to promptly fixing anything that goes wrong with 
 it down the road. Yes, they get a lot less scrutiny. They've 
 earned it.


 Care to give a few names?


 What is your contribution to D?

 As Walter says forks are good. But please go work on your fork 
 and make it great, rather than complaining here.

 If OpenD is good, it will be good competition to D and help 
 spur things. But on the other hand, it requires full time 
 dedicated & knowledgeable people to maintain a language, so it 
 remains to be seen whether anything comes out of the fork.


Yet another person telling "don't complain, just do things", I 
got tired from these, nothing works that way. Complaining is 
needed for improve.


 What is your contribution to D?


The fork, OpenD is pretty enough, contribution doesn't have to be 
directly change in original code.


 But please go work on your fork and make it great, rather than 
 complaining here.


Do you think all people do here is just sit and complain? Do you 
even check OpenD's codebase for updates?



 Jan 16



prev sibling  parent reply Atila Neves <atila.neves gmail.com>  writes:


On Monday, 15 January 2024 at 18:33:07 UTC, H. S. Teoh wrote:

 On Mon, Jan 15, 2024 at 10:11:33AM +0000, IGotD- via 
 Digitalmars-d wrote: [...]

 [...]


 This is true, we have been repeating over the last decade or so 
 the pattern of attracting enthusiastic contributors due to the 
 technical excellence of D, only to have them turn around and 
 leave after coming to an impasse with the project's management. 
  As I have said previously, the problem isn't so much that 
 things did not go their way; I think any reasonable person 
 would understand that in technical decisions there's always 
 pros and cons and one could go either way, and that whichever 
 way a decision goes, it would work out, one could live with it.

 [...]


Thanks for the write-up. I think it's true that these perceptions 
exist, and would like to ask you what you think we can do about 
it.

If I can summarise my own opinions about contributions, it's that 
they're absolutely welcome, but that every change has trade-offs 
and each diff has to justify itself with positive ROI. Of course 
it's going to be frustrating to work for free and not have it pay 
off (it's happened to me multiple times), but it also can't be 
the case that the default is to merge PRs unless "there's a 
reason not to".

My own perception is that we keep saying this, but maybe not? 
Perhaps we need to update the contributor guide.



 Jan 16



 next sibling parent reply Paolo Invernizzi <paolo.invernizzi gmail.com>  writes:


On Tuesday, 16 January 2024 at 10:06:47 UTC, Atila Neves wrote:

 On Monday, 15 January 2024 at 18:33:07 UTC, H. S. Teoh wrote:

 On Mon, Jan 15, 2024 at 10:11:33AM +0000, IGotD- via 
 Digitalmars-d wrote: [...]

 [...]


 This is true, we have been repeating over the last decade or 
 so the pattern of attracting enthusiastic contributors due to 
 the technical excellence of D, only to have them turn around 
 and leave after coming to an impasse with the project's 
 management.  As I have said previously, the problem isn't so 
 much that things did not go their way; I think any reasonable 
 person would understand that in technical decisions there's 
 always pros and cons and one could go either way, and that 
 whichever way a decision goes, it would work out, one could 
 live with it.

 [...]


 Thanks for the write-up. I think it's true that these 
 perceptions exist, and would like to ask you what you think we 
 can do about it.


My humble proposal is to add another, language maintainer with 
good social and technical abilities, (like Steven), and more 
delegation (and trust!) towards 'experts' (Timon ...)


 If I can summarise my own opinions about contributions, it's 
 that they're absolutely welcome, but that every change has 
 trade-offs and each diff has to justify itself with positive 
 ROI. Of course it's going to be frustrating to work for free 
 and not have it pay off (it's happened to me multiple times), 
 but it also can't be the case that the default is to merge PRs 
 unless "there's a reason not to".


That was Andrei way of working, and Theo already wrote about the 
drawbacks of that.

I think you guys should move away from seeing ROI only from a 
technical point of view, you should include also the impact on 
all the other aspect, you should look it at 360 degree.

I think UCORA can really help on that, but you all should first 
recognise that this is a problem, and ask them directly for 
suggestions.

My impression is that this change is happening, slowly but it's 
happening. The elephant entered the room, don't loose this 
opportunity to make a step towards D brilliant future.

/P



 My own perception is that we keep saying this, but maybe not? 
 Perhaps we need to update the contributor guide.





 Jan 16



  parent reply Mike Parker <aldacron gmail.com>  writes:


On Tuesday, 16 January 2024 at 10:45:18 UTC, Paolo Invernizzi 
wrote:


 My humble proposal is to add another, language maintainer with 
 good social and technical abilities, (like Steven), and more 
 delegation (and trust!) towards 'experts' (Timon ...)


I'd just like to say something about this. I've seen it repeated 
that we should delegate, as if we aren't aware of this, or are 
afraid to do it, or whatever. Well, we are aware of it, and we 
aren't afraid to do it.

We do it when we can. Two examples currently in progress: Mathias 
is steadily chipping away at dub issues and Robert is working on 
the Bugzilla to GitHub migration. These are people working in 
their own time, on their own dime, to handle things the DLF asked 
them to handle. Once they became regular members of our monthly 
meetings, then over time they became integral members of the 
team. That makes it a lot easier to ask them to get things done. 
We know what they'd be willing to do.

I periodically reach out to people and ask if they're interested 
in helping us tackle something. Some tell me they'd like to, but 
just don't have the time for it. Others tell me they're happy to, 
then in practice they never find the time for it. That tells me 
they said yes with good intentions, but weren't particularly 
motivated to work on that task.

And that's no slight on them. I totally get it. I might ping a 
time or two over a few weeks, but I'm not going to be pushy about 
it. Very often, they're contributing to the broader community or 
ecosystem in other ways already, anyway.

One of my goals is to alter that situation such that when we have 
any given task, we have a general idea of who would be motivated 
to work on it. To that end, I've been reaching out to some 
long-time D users to expand membership in our monthly meetings 
for the past several months. As a result, we've seen some great 
contributions that otherwise probably wouldn't have materialized 
(and that's in addition to the valuable insights and feedback 
they provide on the topics we discuss). I anticipate that not 
only will we see more such, but we'll be in a better position to 
find alignment with things we need to do and the things those 
members want to achieve, and so we'll be able to delegate more 
tasks more often, and they'll be more willing to get them done.

Of course, I can't expand the monthly meetings indefinitely, so 
I'm also reaching out to chat with other members of the community 
to get a feel for who's interested in doing some of the work we 
need done and what kind best suits them. The more we can make 
that kind of match, the more likely they'll be willing to 
prioritize that work over something they might otherwise be doing 
with their time.

So yes, we want to delegate. We just have to have the right 
environment and the right people to do it. We're working on 
creating that environment for those people.


 I think UCORA can really help on that, but you all should first 
 recognise that this is a problem, and ask them directly for 
 suggestions.


Yes, we are working with Ucora already. Walter and I are 
participating in their executive coaching program. We just had a 
few weeks off for the holidays, but we're back in the saddle this 
week.


 My impression is that this change is happening, slowly but it's 
 happening.


Yes. Unfortunately, slowly is the name of the game for now. But 
I'm optimistic we'll pick up momentum over the next few months. 
We've got Ucora's advice and guidance, but they aren't pushing 
any sort of structures or frameworks on us. We (the DLF) have to 
build up our processes ourselves in a way that makes sense for 
us. It's not going to happen overnight, nor anywhere as quickly 
as we'd like it to. But we are finding our way.


 Perhaps we need to update the contributor guide.




That's one of the things on our TODO list. That falls to Razvan 
and Dennis as our pull request and issue managers. I've discussed 
it with them already in our regular weekly meetings.



 Jan 16



 next sibling parent  Sergey <kornburn yandex.ru>  writes:


On Tuesday, 16 January 2024 at 12:50:35 UTC, Mike Parker wrote:

 On Tuesday, 16 January 2024 at 10:45:18 UTC, Paolo Invernizzi


It is all good, the only problem in my (with limited information 
what I can see of course), that DLF acting like a billion 
corporate, but in reality at least in current situation it is 
very small start-up..



 Jan 16



prev sibling  parent reply Paolo Invernizzi <paolo.invernizzi gmail.com>  writes:


On Tuesday, 16 January 2024 at 12:50:35 UTC, Mike Parker wrote:

 On Tuesday, 16 January 2024 at 10:45:18 UTC, Paolo Invernizzi 
 wrote:


 [...]


 I'd just like to say something about this. I've seen it 
 repeated that we should delegate, as if we aren't aware of 
 this, or are afraid to do it, or whatever. Well, we are aware 
 of it, and we aren't afraid to do it.

 [...]


Thank you Mike, just one point about delegation.

It's not only related to the 'do that _specific_ things': you 
wrote about issues on dub, task about migrations. "to handle 
things the DLF asked them to handle", you wrote.

I'm referring to delegation for _judgements_ on specific aspect 
of D ecosystem: we are seeing it right now, an incredible amount 
of effort spent by a lot of people to "justify" why CT string 
interpolation is not a 'nice-to-have'.

The net gain for _everybody_ , Walter included, would have been 
to simply delegate that specific judgement to Timon: yes, we need 
full CT capable interpolation solution, let's tackle the next 
point.

Anyway, things are moving, and that's good.

/P



 Jan 16



 next sibling parent  aberba <karabutaworld gmail.com>  writes:


On Tuesday, 16 January 2024 at 14:38:36 UTC, Paolo Invernizzi 
wrote:

 On Tuesday, 16 January 2024 at 12:50:35 UTC, Mike Parker wrote:

 On Tuesday, 16 January 2024 at 10:45:18 UTC, Paolo Invernizzi 
 wrote:


 [...]


 I'd just like to say something about this. I've seen it 
 repeated that we should delegate, as if we aren't aware of 
 this, or are afraid to do it, or whatever. Well, we are aware 
 of it, and we aren't afraid to do it.

 [...]


 Thank you Mike, just one point about delegation.

 It's not only related to the 'do that _specific_ things': you 
 wrote about issues on dub, task about migrations. "to handle 
 things the DLF asked them to handle", you wrote.

 I'm referring to delegation for _judgements_ on specific aspect 
 of D ecosystem: we are seeing it right now, an incredible 
 amount of effort spent by a lot of people to "justify" why CT 
 string interpolation is not a 'nice-to-have'.

 The net gain for _everybody_ , Walter included, would have been 
 to simply delegate that specific judgement to Timon: yes, we 
 need full CT capable interpolation solution, let's tackle the 
 next point.


Delegation of judgement 👍. I don't think Walter is an expert at 
everything. So what it means is anything he doesn't understand 
isn't getting in the language. I think Andrei and Co were onetime 
trusted to do many things and that's what set D2 apart. That very 
function is currently missing


 Anyway, things are moving, and that's good.

 /P





 Jan 16



prev sibling  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 1/16/2024 6:38 AM, Paolo Invernizzi wrote:

 I'm referring to delegation for _judgements_ on specific aspect of D
ecosystem: 
 we are seeing it right now, an incredible amount of effort spent by a lot of 
 people to "justify" why CT string interpolation is not a 'nice-to-have'.


Both proposals can do CT string interpolation.

There are misunderstandings about both proposals.

I suspect if we all sat down in a room together, we'd have it resolved within
an 
hour.



 The net gain for _everybody_ , Walter included, would have been to simply 
 delegate that specific judgement to Timon


I've never caught Timon in a technical error, he's a genius as far as I can 
tell! But we disagree now and then on the value of various inevitable
tradeoffs. 
This stems from our different backgrounds.



 Jan 16



 next sibling parent reply Elias (0xEAB) <desisma heidel.beer>  writes:


On Tuesday, 16 January 2024 at 20:18:00 UTC, Walter Bright wrote:

 I suspect if we all sat down in a room together, we'd have it 
 resolved within an hour.


While I’m not sure whether this would work out in practice from 
the organizational perspective, it sounds like a great idea.



 Jan 16



 next sibling parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 1/16/2024 12:24 PM, Elias (0xEAB) wrote:

 On Tuesday, 16 January 2024 at 20:18:00 UTC, Walter Bright wrote:

 I suspect if we all sat down in a room together, we'd have it resolved within 
 an hour.


 
 While I’m not sure whether this would work out in practice from the 
 organizational perspective, it sounds like a great idea.


It's happened before. It's one reason why our annual in-person conference is so 
valuable. Sitting around the same table, perhaps with a beer(!), works wonders.



 Jan 16



  parent reply matheus <matheus gmail.com>  writes:


On Tuesday, 16 January 2024 at 20:45:58 UTC, Walter Bright wrote:

 On 1/16/2024 12:24 PM, Elias (0xEAB) wrote:
 ...
 It's happened before. It's one reason why our annual in-person 
 conference is so valuable. Sitting around the same table, 
 perhaps with a beer(!), works wonders.


I work as developer in a pretty much one of biggest health care 
companies in my Country. We have developers scattered across all 
the country, so we do pretty much everything online. Last week we 
were having a problem with one system, we stayed all day long 
talking about it over text (Chat), I had a solution but 
unfortunately some teams wasn't understanding and 
miscommunication was occurring and some people was entering the 
chat later and asking the same things over and over.

The next day in the morning I was called again to explain the 
solution for a new team, then I asked everybody to go online 
(Video call).

Believe or not in less than 10 minutes we were finished.

This was not the first time this happened, where texts (Chat or 
e-mail) keep going around and nothing moves until we go online.

I think sometimes this group lack of this kind of thing. I even 
posted in another thread about String Interpolation that this 
should be resolved faster if you were online.

That's it,

Matheus.



 Jan 16



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 1/16/2024 3:49 PM, matheus wrote:

 I think sometimes this group lack of this kind of thing. I even posted in 
 another thread about String Interpolation that this should be resolved faster
if 
 you were online.


texting < newsgroup < phone < zoom meeting < in-person meeting



 Jan 16



prev sibling  parent  Jonathan M Davis <newsgroup.d jmdavisprog.com>  writes:


On Tuesday, January 16, 2024 1:24:04 PM MST Elias (0xEAB) via Digitalmars-d 
wrote:

 On Tuesday, 16 January 2024 at 20:18:00 UTC, Walter Bright wrote:

 I suspect if we all sat down in a room together, we'd have it
 resolved within an hour.


 While I’m not sure whether this would work out in practice from
 the organizational perspective, it sounds like a great idea.


Among other things, that's how we got the package.d feature. Daniel Murphy
and I discussed it at length with Walter at dconf (either in 2013 or 2014)
at a table in the hotel, because we were looking for a way to split up
std.datetime without breaking existing code. And ultimately, package.d was
the result. Who knows whether that would have occurred if we hadn't been
able to sit down and discuss it in person like that. And I'm sure that there
are plenty of other examples of stuff that's come out of dconf or other D
meetups. That's just the one that comes to mind for me first.

- Jonathan M Davis



 Jan 16



prev sibling  parent reply Paolo Invernizzi <paolo.invernizzi gmail.com>  writes:


On Tuesday, 16 January 2024 at 20:18:00 UTC, Walter Bright wrote:

 On 1/16/2024 6:38 AM, Paolo Invernizzi wrote:

 I'm referring to delegation for _judgements_ on specific 
 aspect of D ecosystem: we are seeing it right now, an 
 incredible amount of effort spent by a lot of people to 
 "justify" why CT string interpolation is not a 'nice-to-have'.


 Both proposals can do CT string interpolation.

 There are misunderstandings about both proposals.

 I suspect if we all sat down in a room together, we'd have it 
 resolved within an hour.


Yeah, I know, I manage people since I was 25 and I'm 54 now: I've 
learned that nothing settles down misunderstandings better than 
having a beer.


 The net gain for _everybody_ , Walter included, would have 
 been to simply delegate that specific judgement to Timon


 I've never caught Timon in a technical error, he's a genius as 
 far as I can tell! But we disagree now and then on the value of 
 various inevitable tradeoffs. This stems from our different 
 backgrounds.


Different backgrounds are valuables, especially since also you 
are genius in engineering, hey, a C++ compiler written by a solo 
man!



 Jan 16



 next sibling parent  "H. S. Teoh" <hsteoh qfbox.info>  writes:


On Tue, Jan 16, 2024 at 10:17:35PM +0000, Paolo Invernizzi via Digitalmars-d
wrote:

 On Tuesday, 16 January 2024 at 20:18:00 UTC, Walter Bright wrote:


[...]

 I suspect if we all sat down in a room together, we'd have it
 resolved within an hour.


 
 Yeah, I know, I manage people since I was 25 and I'm 54 now: I've
 learned that nothing settles down misunderstandings better than having
 a beer.


[...]

Meeting in person solves 90% of communication problems.  Although online
communication preserves the textual content of a message, it often fails
to convey the emotional and implicit contents, and lacks facial / body
language cues, which are equally important parts of human communication.
Video communication is somewhat better in preserving the facial cue
component, but often still lacks (most of) the body language.


T

-- 
Designer clothes: how to cover less by paying more.



 Jan 16



prev sibling  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 1/16/2024 2:17 PM, Paolo Invernizzi wrote:

 Different backgrounds are valuables, especially since also you are genius in 
 engineering, hey, a C++ compiler written by a solo man!


I appreciated working with Andrei because he had the academic background I 
lacked, while I had the "boots on the ground" experience.



 Jan 17



prev sibling next sibling parent reply Dukc <ajieskola gmail.com>  writes:


On Tuesday, 16 January 2024 at 10:06:47 UTC, Atila Neves wrote:

 but it also can't be the case that the default is to merge PRs 
 unless "there's a reason not to".


Why not? I get that such PRs are not necessarily net positives in 
purely technical sense, but if there's no reason not to merge 
them they can't be big technical negatives either.

If accepting PRs like that helps to keep people around, then 
considering the morale effect, I'd argue merging such PRs is 
still a net positive.



 Jan 16



  parent reply Don Allen <donaldcallen gmail.com>  writes:


On Tuesday, 16 January 2024 at 10:47:11 UTC, Dukc wrote:

 On Tuesday, 16 January 2024 at 10:06:47 UTC, Atila Neves wrote:

 but it also can't be the case that the default is to merge PRs 
 unless "there's a reason not to".


 Why not? I get that such PRs are not necessarily net positives 
 in purely technical sense, but if there's no reason not to 
 merge them they can't be big technical negatives either.

 If accepting PRs like that helps to keep people around, then 
 considering the morale effect, I'd argue merging such PRs is 
 still a net positive.


This is an excellent point that I think Walter and the others who 
manage this project need to take very seriously. The 
technical-social balance of this project is clearly skewed, the 
evidence being a long-term pattern of talented people heading for 
the exits.



 Jan 16



  parent reply Dibyendu Majumdar <d.majumdar gmail.com>  writes:


On Tuesday, 16 January 2024 at 13:42:36 UTC, Don Allen wrote:

 On Tuesday, 16 January 2024 at 10:47:11 UTC, Dukc wrote:

 On Tuesday, 16 January 2024 at 10:06:47 UTC, Atila Neves wrote:

 but it also can't be the case that the default is to merge 
 PRs unless "there's a reason not to".


 Why not? I get that such PRs are not necessarily net positives 
 in purely technical sense, but if there's no reason not to 
 merge them they can't be big technical negatives either.

 If accepting PRs like that helps to keep people around, then 
 considering the morale effect, I'd argue merging such PRs is 
 still a net positive.


 This is an excellent point that I think Walter and the others 
 who manage this project need to take very seriously. The 
 technical-social balance of this project is clearly skewed, the 
 evidence being a long-term pattern of talented people heading 
 for the exits.


Not at all a good idea. The D team is the gate keeper of the 
language and have to ensure that each feature integrates with the 
whole. Saying yes to every feature by default is complete 
madness. There is a huge cost to every new feature.

Worth watching https://www.youtube.com/watch?v=gXdS3IftP0Y

D is arguably already too full of features because of trying to 
please everyone.
As someone argued, its better to focus on quality rather than 
features at this stage.



 Jan 16



 next sibling parent reply Dukc <ajieskola gmail.com>  writes:


On Tuesday, 16 January 2024 at 14:03:20 UTC, Dibyendu Majumdar 
wrote:

 Not at all a good idea. The D team is the gate keeper of the 
 language and have to ensure that each feature integrates with 
 the whole. Saying yes to every feature by default is complete 
 madness. There is a huge cost to every new feature.


When adding new language features it makes sense that the bar is 
somewhat higher, to the point that the feature has to justify 
itself. But for internal changes, minor enhancements and bug 
fixes it's better to have "accept when technically neutral" 
stance.

For an open-source project contributor enthusiasm is a central 
resource, much like money is for a commercial company. It's what 
makes the project to run. Hence anything that people have wish to 
do on their own initiative should be considered much cheaper 
relative to the needed man-hours than less popular work. Same for 
hanging a PR up because of relatively trivial nitpicks. If 
addressing some nitpicks takes the contributor 30% more time but 
leaves him feeling like "not going to do again", the cost of 
those nitpicks was far more than 30% of the original work.



 Jan 16



  parent reply Lance Bachmeier <no spam.net>  writes:


On Tuesday, 16 January 2024 at 14:24:09 UTC, Dukc wrote:


 For an open-source project contributor enthusiasm is a central 
 resource, much like money is for a commercial company. It's 
 what makes the project to run. Hence anything that people have 
 wish to do on their own initiative should be considered much 
 cheaper relative to the needed man-hours than less popular 
 work. Same for hanging a PR up because of relatively trivial 
 nitpicks. If addressing some nitpicks takes the contributor 30% 
 more time but leaves him feeling like "not going to do again", 
 the cost of those nitpicks was far more than 30% of the 
 original work.


The reason I don't want to contribute is because the standard 
isn't "Does it pass the tests it's supposed to pass?" and "Is it 
written in an idiomatic style?", the standard is instead the 
reviewer asking "Is the code written the way I would have written 
it?" I just don't have time for that.



 Jan 16



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 1/16/2024 8:13 AM, Lance Bachmeier wrote:

 The reason I don't want to contribute is because the standard isn't "Does it 
 pass the tests it's supposed to pass?" and "Is it written in an idiomatic 
 style?", the standard is instead the reviewer asking "Is the code written the 
 way I would have written it?" I just don't have time for that.


The larger a project is, the more useful a consistent style is across it.

Though dmd/phobos/druntime each have a different style to them, as do the 
various other projects that are part of D.

Or maybe you mean something else?



 Jan 17



  parent reply bachmeier <no spam.net>  writes:


On Thursday, 18 January 2024 at 03:17:45 UTC, Walter Bright wrote:

 On 1/16/2024 8:13 AM, Lance Bachmeier wrote:

 The reason I don't want to contribute is because the standard 
 isn't "Does it pass the tests it's supposed to pass?" and "Is 
 it written in an idiomatic style?", the standard is instead 
 the reviewer asking "Is the code written the way I would have 
 written it?" I just don't have time for that.


 The larger a project is, the more useful a consistent style is 
 across it.

 Though dmd/phobos/druntime each have a different style to them, 
 as do the various other projects that are part of D.

 Or maybe you mean something else?


Any such rules need to be stated up front. If they're written 
down, I don't know where they are. Nobody wants to find out after 
the fact that their work will be rejected if they don't reformat 
it (as one simple example).



 Jan 17



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 1/17/2024 7:49 PM, bachmeier wrote:

  Nobody wants to find out after the fact that their work will be 
 rejected if they don't reformat it (as one simple example).



https://dlang.org/dstyle.html

https://wiki.dlang.org/Phobos_and_Druntime_Style_Guide

A style checker is also run over PRs as part of the test suite. (I didn't write 
the style checker nor specify what it does.)



 Jan 17



prev sibling  parent reply Don Allen <donaldcallen gmail.com>  writes:


On Tuesday, 16 January 2024 at 14:03:20 UTC, Dibyendu Majumdar 
wrote:

 On Tuesday, 16 January 2024 at 13:42:36 UTC, Don Allen wrote:

 On Tuesday, 16 January 2024 at 10:47:11 UTC, Dukc wrote:

 On Tuesday, 16 January 2024 at 10:06:47 UTC, Atila Neves 
 wrote:

 but it also can't be the case that the default is to merge 
 PRs unless "there's a reason not to".


 Why not? I get that such PRs are not necessarily net 
 positives in purely technical sense, but if there's no reason 
 not to merge them they can't be big technical negatives 
 either.

 If accepting PRs like that helps to keep people around, then 
 considering the morale effect, I'd argue merging such PRs is 
 still a net positive.


 This is an excellent point that I think Walter and the others 
 who manage this project need to take very seriously. The 
 technical-social balance of this project is clearly skewed, 
 the evidence being a long-term pattern of talented people 
 heading for the exits.


 Not at all a good idea. The D team is the gate keeper of the 
 language and have to ensure that each feature integrates with 
 the whole. Saying yes to every feature by default is complete 
 madness. There is a huge cost to every new feature.


I won't speak for Dukc, but I am certainly not advocating "saying 
yes to every feature". That's open-loop stupidity. What *is* 
being advocated is better balance between technical and social 
considerations, which has to be applied on a case-by-case basis.

And there will (or should) be cases that might be rejected solely 
on technical grounds that should be accepted by also considering 
the social cost of rejection. The whole point is to maximize the 
welfare, the forward progress, of the project. These are 
judgement calls that the project leaders need to make and the 
evidence indicates that the way they do it needs adjustment.

Case in point -- the OpenBSD project, for longer than you might 
think was sane, supported the Vax. Why? Because there were some 
people who were making valuable contributions to the project that 
cared about the Vax for some reason and Theo de Raadt, the 
project leader, decided that the cost of indulging them was 
worthwhile, given the benefits of keeping these people around.


 Worth watching https://www.youtube.com/watch?v=gXdS3IftP0Y

 D is arguably already too full of features because of trying to 
 please everyone.
 As someone argued, its better to focus on quality rather than 
 features at this stage.





 Jan 16



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


In general, we've been much more willing to accept PRs that we can back out of 
if they don't turn out well.

For example, improvements to debug support, better code generation,
stdatomic.d, 
fixing bugs, adding statistics to dmd's output, things like that.

Language changes, though, have a much higher bar. The risk there is people rely 
on it, and then we're stuck with it forever.

For example, `alias this` for classes. The semantics of it were never defined 
properly, and with many attempts at figuring what the correct semantics must
be, 
never found one that anybody could defend. Worse, many people were using it for 
classes, and and relied on whatever the compiler did for it.

Hence, we did not want to deprecated it. Instead, we froze its current
behavior, 
and I opposed any further additions to it and/or attempts to fix it. All I can 
do is just recommend people not use `alias this` in classes.

Rikki's proposal to do UAX31 identifiers I was initially opposed to, but upon 
reflection realized there was more risk in not doing it than doing it, and so 
full speed ahead, Rikki!



 Jan 16



  parent reply DrDread <DrDread cheese.com>  writes:


On Tuesday, 16 January 2024 at 20:07:08 UTC, Walter Bright wrote:

 In general, we've been much more willing to accept PRs that we 
 can back out of if they don't turn out well.

 For example, improvements to debug support, better code 
 generation, stdatomic.d, fixing bugs, adding statistics to 
 dmd's output, things like that.

 Language changes, though, have a much higher bar. The risk 
 there is people rely on it, and then we're stuck with it 
 forever.

 For example, `alias this` for classes. The semantics of it were 
 never defined properly, and with many attempts at figuring what 
 the correct semantics must be, never found one that anybody 
 could defend. Worse, many people were using it for classes, and 
 and relied on whatever the compiler did for it.

 Hence, we did not want to deprecated it. Instead, we froze its 
 current behavior, and I opposed any further additions to it 
 and/or attempts to fix it. All I can do is just recommend 
 people not use `alias this` in classes.

 Rikki's proposal to do UAX31 identifiers I was initially 
 opposed to, but upon reflection realized there was more risk in 
 not doing it than doing it, and so full speed ahead, Rikki!


and this is also a problem. you leave bad features in the 
language that turned out to not work proberly, instead of just 
deprecating them.
people don't mind breaking code as much as you think, as long as 
it doesn't silently break. D doesn't have the adoption rate where 
not breaking code is justified in any way.



 Jan 18



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 1/18/2024 3:14 AM, DrDread wrote:

 and this is also a problem. you leave bad features in the language that turned 
 out to not work proberly, instead of just deprecating them.
 people don't mind breaking code as much as you think, as long as it doesn't 
 silently break.


We recently has a long, acrimonious thread with people complaining that D would 
break their existing code, and not silently.



 Jan 18



  parent  Lance Bachmeier <no spam.net>  writes:


On Thursday, 18 January 2024 at 22:36:39 UTC, Walter Bright wrote:

 On 1/18/2024 3:14 AM, DrDread wrote:

 and this is also a problem. you leave bad features in the 
 language that turned out to not work proberly, instead of just 
 deprecating them.
 people don't mind breaking code as much as you think, as long 
 as it doesn't silently break.


 We recently has a long, acrimonious thread with people 
 complaining that D would break their existing code, and not 
 silently.


My understanding is that you now have a plan in place to change 
the language without breaking old code. Hopefully it works, 
because it will be one of the most important changes in the time 
I've used D.



 Jan 18



prev sibling  parent reply Paul Backus <snarwin gmail.com>  writes:


On Tuesday, 16 January 2024 at 10:06:47 UTC, Atila Neves wrote:

 If I can summarise my own opinions about contributions, it's 
 that they're absolutely welcome, but that every change has 
 trade-offs and each diff has to justify itself with positive 
 ROI. Of course it's going to be frustrating to work for free 
 and not have it pay off (it's happened to me multiple times), 
 but it also can't be the case that the default is to merge PRs 
 unless "there's a reason not to".

 My own perception is that we keep saying this, but maybe not? 
 Perhaps we need to update the contributor guide.


With due respect, I think focusing on acceptance vs rejection of 
PRs is completely missing the point here.

People like Adam Ruppe and Sebastian Wilzbach understand 
perfectly well that not every contribution is going to be 
accepted. They don't leave just because they can't get their way. 
They leave because they feel *personally* disrespected and 
insulted in their interactions with D's leadership.

When their contributions are ignored, and they have to wait weeks 
or even months to get so much as an acknowledgement (let alone a 
review) from leadership  [1], they feel personally disrespected 
and insulted.

When their good-faith technical arguments are dismissed by 
someone "pulling rank" without addressing the actual points [2], 
they feel personally disrespected and insulted.

When they put time and effort into following the proper process 
for their contributions, only to see leadership turn around and 
ignore that process when it suits them [3], they feel personally 
disrespected and insulted.

I understand that you and Walter do not *intend* to insult 
contributors or to treat them with disrespect, but you need to 
recognize that, in practice, that's what you've been doing, and 
good intentions do not absolve you of responsibility for it. And 
you need to stop doing it, because if you don't, it's going to 
kill D.

The simple fact is, D needs people like Adam Ruppe and Sebastian 
Wilzbach more than those people need D. D's leadership cannot 
afford to insult and disrespect its contributors until they run 
out of patience and leave for greener pastures. And D's 
leadership *especially* cannot afford to cement D in the minds of 
*potential* contributors as a language whose leadership is 
disrespectful, unprofessional, and frustrating to work with.

OpenD was on the front page of both Hacker News and Reddit's 
/r/programming this week. What effect do you think that's had on 
D's reputation? On its ability to attract new contributors?

This fork should have been a wakeup call, but already, looking at 
this thread, I can see that the wrong lessons are being learned. 
This is not about whether or not PRs get merged. It's about 
giving contributors the respect and acknowledgement they 
deserve--not just with your words, but with your actions, your 
effort, and your time.

D is a great language, and a great community. All of us here, I 
think, want to see it succeed. Please don't let us down.

[1] https://github.com/dlang/dmd/pull/15715
[2] https://github.com/dlang/dmd/pull/12828
[3] https://github.com/dlang/dmd/pull/12507



 Jan 16



 next sibling parent  "H. S. Teoh" <hsteoh qfbox.info>  writes:


On Tue, Jan 16, 2024 at 11:20:59PM +0000, Paul Backus via Digitalmars-d wrote:
[...]

 With due respect, I think focusing on acceptance vs rejection of PRs
 is completely missing the point here.


Spot on!



 People like Adam Ruppe and Sebastian Wilzbach understand perfectly
 well that not every contribution is going to be accepted. They don't
 leave just because they can't get their way. They leave because they
 feel *personally* disrespected and insulted in their interactions with
 D's leadership.


[...]

 I understand that you and Walter do not *intend* to insult
 contributors or to treat them with disrespect, but you need to
 recognize that, in practice, that's what you've been doing, and good
 intentions do not absolve you of responsibility for it. And you need
 to stop doing it, because if you don't, it's going to kill D.


Yes, this is exactly what I've been trying to say (unsuccessfully, it
seems).  Thank you for spelling it out.  Hopefully in a clear enough way
that the message gets through.

Because if this continues, D is indeed going to die.  It may be a slow,
painful death, but it will die.  Die from long-time contributors finally
deciding to throw in the towel.  Die from not being able to gain (and
retain) new contributors to replace them.  And that would indeed be a
huge tragedy.  D is a great language, and has so much potential.  For it
to go to waste, because its leadership refuses to acknowledge and fix a
social problem that has become glaringly, blindingly obvious to any
unbiased observer over the past decade or more, would be a great tragedy
indeed.



 The simple fact is, D needs people like Adam Ruppe and Sebastian
 Wilzbach more than those people need D.


Yes.  There's an entire series of contributors who, had they stayed,
would have made a HUGE difference in D.  How many more do we need to
lose before we wake up?



 D's leadership cannot afford to insult and disrespect its contributors
 until they run out of patience and leave for greener pastures. And D's
 leadership *especially* cannot afford to cement D in the minds of
 *potential* contributors as a language whose leadership is
 disrespectful, unprofessional, and frustrating to work with.


Exactly.  We're already having manpower problems.  Had been having them
for a very long time now.  If this continues, in all likelihood it will
get worse.  And may well reach the point where it will actually kill D.



 OpenD was on the front page of both Hacker News and Reddit's
 /r/programming this week. What effect do you think that's had on D's
 reputation? On its ability to attract new contributors?
 
 This fork should have been a wakeup call, but already, looking at this
 thread, I can see that the wrong lessons are being learned. This is
 not about whether or not PRs get merged. It's about giving
 contributors the respect and acknowledgement they deserve--not just
 with your words, but with your actions, your effort, and your time.


+100.  This fork has never been about the string interpolation PR. Nor
about some pet feature that got rejected.  All of that is only
incidental. The REAL problem is the lack of respect and acknowledgement,
not necessarily in word but certainly in action, that has accumulated
over years, even decades, until finally the camel's back snapped.

To merely remove that one last straw and think that the camel is now OK,
completely misses the point.  The remainder of the burden is still on
the camel's back.  It won't take much before another straw is piled on
and the camel's back will break again.  Soon there will be no more
camels left, and D will be stranded, maybe forever, in the middle of the
desert of obscurity with nowhere else to go.



 D is a great language, and a great community. All of us here, I think,
 want to see it succeed. Please don't let us down.


[...]

As others have already said, this is a critical juncture for D.  If the
current leadership continues its present course, openD may very well
become D's replacement.  Or it may not, and both will die.  That is also
a very real possibility.

The best hope for D is really if the leadership could be reconciled with
the openD folk, and both could work together to improve D.  Adam has
told me personally that this would be the best outcome.  However, he is
not holding his breath.  Please prove him wrong.  Because the other
alternatives all suck.


T

-- 
People tell me that I'm paranoid, but they're just out to get me.



 Jan 16



prev sibling  parent reply Atila Neves <atila.neves gmail.com>  writes:


On Tuesday, 16 January 2024 at 23:20:59 UTC, Paul Backus wrote:

Thanks for the write up.


 On Tuesday, 16 January 2024 at 10:06:47 UTC, Atila Neves wrote:

 [...]


 With due respect, I think focusing on acceptance vs rejection 
 of PRs is completely missing the point here.


I appreciate you pointing that out.



 People like Adam Ruppe and Sebastian Wilzbach understand 
 perfectly well that not every contribution is going to be 
 accepted. They don't leave just because they can't get their 
 way. They leave because they feel *personally* disrespected and 
 insulted in their interactions with D's leadership.

 When their contributions are ignored, and they have to wait 
 weeks or even months to get so much as an acknowledgement (let 
 alone a review) from leadership  [1], they feel personally 
 disrespected and insulted.


I wrote a spec for that PR and tried to keep Adam informed about 
my progress as it was going on. I'm not sure what else I could 
have done in this specific case other than do it sooner, I'm more 
than willing to listen to suggestions. I'm still trying to get it 
merged.


 The simple fact is, D needs people like Adam Ruppe and 
 Sebastian Wilzbach more than those people need D. D's 
 leadership cannot afford to insult and disrespect its 
 contributors until they run out of patience and leave for 
 greener pastures. And D's leadership *especially* cannot afford 
 to cement D in the minds of *potential* contributors as a 
 language whose leadership is disrespectful, unprofessional, and 
 frustrating to work with.


I agree.


 This fork should have been a wakeup call, but already, looking 
 at this thread, I can see that the wrong lessons are being 
 learned.


FWIW, it definitely was a wakeup call, at least for me.


 This is not about whether or not PRs get merged. It's about 
 giving contributors the respect and acknowledgement they 
 deserve--not just with your words, but with your actions, your 
 effort, and your time.


I hear you.



 Jan 17



 next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz>  writes:


On 18/01/2024 5:02 AM, Atila Neves wrote:

     The simple fact is, D needs people like Adam Ruppe and Sebastian
     Wilzbach more than those people need D. D's leadership cannot afford
     to insult and disrespect its contributors until they run out of
     patience and leave for greener pastures. And D's leadership
     /especially/ cannot afford to cement D in the minds of /potential/
     contributors as a language whose leadership is disrespectful,
     unprofessional, and frustrating to work with.
 
 I agree.
 
     This fork should have been a wakeup call, but already, looking at
     this thread, I can see that the wrong lessons are being learned.
 
 FWIW, it definitely was a wakeup call, at least for me.


To be blunt, you and Walter are never on Discord, or anywhere where 
people are normally talking socially.

In general, you're simply not active enough and on the ball about things 
to be doing the role you have.

If there is a problem you quite often don't hear about it unless it goes 
through us long timers and even then it could take months.

I personally have had problems with you not following up on things. That 
is not conducive towards getting people to contribute.



 Jan 17



 next sibling parent  Paolo Invernizzi <paolo.invernizzi gmail.com>  writes:


On Wednesday, 17 January 2024 at 16:13:27 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 On 18/01/2024 5:02 AM, Atila Neves wrote:

     The simple fact is, D needs people like Adam Ruppe and 
 Sebastian
     Wilzbach more than those people need D. D's leadership 
 cannot afford
     to insult and disrespect its contributors until they run 
 out of
     patience and leave for greener pastures. And D's leadership
     /especially/ cannot afford to cement D in the minds of 
 /potential/
     contributors as a language whose leadership is 
 disrespectful,
     unprofessional, and frustrating to work with.
 
 I agree.
 
     This fork should have been a wakeup call, but already, 
 looking at
     this thread, I can see that the wrong lessons are being 
 learned.
 
 FWIW, it definitely was a wakeup call, at least for me.


 To be blunt, you and Walter are never on Discord, or anywhere 
 where people are normally talking socially.

 In general, you're simply not active enough and on the ball 
 about things to be doing the role you have.

 If there is a problem you quite often don't hear about it 
 unless it goes through us long timers and even then it could 
 take months.

 I personally have had problems with you not following up on 
 things. That is not conducive towards getting people to 
 contribute.


I think that this thread is now going in the wrong direction, 
what can be obtained in asking people things that can't provide? 
This thread is improving trust or is mining it? Why ask Atila / 
Walter to be different?

More _delegation_ in _taking decisions_ is needed, and to archive 
that, trust in decisions taken by delegated people is needed.

Procedures and roles are to be revamped to improve the way D is 
managed, taking in account that emerged by the "wakeup call"? 
Well, to my understanding that's someone that can provide 
professional advices on what to change and how to change it, or 
at least can mentor the DLF on that road: UCORA people, they are 
professional on that, it's their job.

Is that feasible? If yes, let's try to be constructive on that.



 Jan 17



prev sibling  parent reply Atila Neves <atila.neves gmail.com>  writes:


On Wednesday, 17 January 2024 at 16:13:27 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 On 18/01/2024 5:02 AM, Atila Neves wrote:

     The simple fact is, D needs people like Adam Ruppe and 
 Sebastian
     Wilzbach more than those people need D. D's leadership 
 cannot afford
     to insult and disrespect its contributors until they run 
 out of
     patience and leave for greener pastures. And D's leadership
     /especially/ cannot afford to cement D in the minds of 
 /potential/
     contributors as a language whose leadership is 
 disrespectful,
     unprofessional, and frustrating to work with.
 
 I agree.
 
     This fork should have been a wakeup call, but already, 
 looking at
     this thread, I can see that the wrong lessons are being 
 learned.
 
 FWIW, it definitely was a wakeup call, at least for me.


 To be blunt, you and Walter are never on Discord,


I've tried multiple times. There's usually 200+ unread messages 
and they keep coming in pretty quickly. I don't think I'd have 
time to read half of what ends up on Discord even if D were my 
full-time job.


 or anywhere where people are normally talking socially.


Other than Discord, where's that? And how would I find the time 
to do Discord *and* this? I'm not convinced I need to hear 
everything that's going on, but I'm open to hearing the merits. 
It's not the same thing, but CEOs aren't expected to be hanging 
around on slack either.


 If there is a problem you quite often don't hear about it 
 unless it goes through us long timers and even then it could 
 take months.


I'm not aware of any examples, but I believe you. Besides 
Discord, what do you suggest I do to avoid that in the future? 
I've been relying on Github mentions.


 I personally have had problems with you not following up on 
 things. That is not conducive towards getting people to 
 contribute.


Yes, I remember, and sorry about that again.



 Jan 18



  parent  "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz>  writes:


Don't worry about all the talk beyond one page back. If you are needed 
you would be pinged. Even I as a moderator apply this approach.

As long as you're there, talking occasionally and able to respond if 
there is a ping, we're golden. Otherwise ignore anything you're not 
interested in.

Being available if needed is enough. Nobody expects you or anyone else 
to be a superhuman.



 Jan 18



prev sibling  parent reply Paul Backus <snarwin gmail.com>  writes:


On Wednesday, 17 January 2024 at 16:02:28 UTC, Atila Neves wrote:

 On Tuesday, 16 January 2024 at 23:20:59 UTC, Paul Backus wrote:

 People like Adam Ruppe and Sebastian Wilzbach understand 
 perfectly well that not every contribution is going to be 
 accepted. They don't leave just because they can't get their 
 way. They leave because they feel *personally* disrespected 
 and insulted in their interactions with D's leadership.

 When their contributions are ignored, and they have to wait 
 weeks or even months to get so much as an acknowledgement (let 
 alone a review) from leadership  [1], they feel personally 
 disrespected and insulted.


 I wrote a spec for that PR and tried to keep Adam informed 
 about my progress as it was going on. I'm not sure what else I 
 could have done in this specific case other than do it sooner, 
 I'm more than willing to listen to suggestions. I'm still 
 trying to get it merged.


The problem is not what you did in this specific case; it's the 
fact that, by the time he submitted the DIP 1036e PR, Adam's 
relationship with D's leadership had *already* deteriorated so 
much that he felt only drastic action would get his point across.

What you (and Walter, and Andrei) could, and should, have done is 
spent the last 10+ years treating Adam with the respect and 
professionalism he deserved. What you can, and must, do now is 
(a) determine why you failed to do so, and (b) make plans to 
ensure that those failures do not recur in the future (either 
with Adam, should he return, or with other contributors).



 Jan 17



 next sibling parent reply Adam Wilson <flyboynw gmail.com>  writes:


On Wednesday, 17 January 2024 at 18:28:33 UTC, Paul Backus wrote:

 What you (and Walter, and Andrei) could, and should, have done 
 is spent the last 10+ years treating Adam with the respect and 
 professionalism he deserved. What you can, and must, do now is 
 (a) determine why you failed to do so, and (b) make plans to 
 ensure that those failures do not recur in the future (either 
 with Adam, should he return, or with other contributors).


Professional respect is both earned and revocable. Mr. Ruppe did 
himself no favors during the November community call (don't know 
if I can say more than that). Extreme frustration is not, and 
never can be, an excuse from professional decorum. Mr. Wilzbach 
handled it much better. IMO, the leadership dealt with Mr. Ruppe 
about as charitably as one could hope for.



 Jan 17



 next sibling parent  Paul Backus <snarwin gmail.com>  writes:


On Thursday, 18 January 2024 at 01:56:32 UTC, Adam Wilson wrote:

 On Wednesday, 17 January 2024 at 18:28:33 UTC, Paul Backus 
 wrote:

 What you (and Walter, and Andrei) could, and should, have done 
 is spent the last 10+ years treating Adam with the respect and 
 professionalism he deserved. What you can, and must, do now is 
 (a) determine why you failed to do so, and (b) make plans to 
 ensure that those failures do not recur in the future (either 
 with Adam, should he return, or with other contributors).


 Professional respect is both earned and revocable. Mr. Ruppe 
 did himself no favors during the November community call (don't 
 know if I can say more than that). Extreme frustration is not, 
 and never can be, an excuse from professional decorum. Mr. 
 Wilzbach handled it much better. IMO, the leadership dealt with 
 Mr. Ruppe about as charitably as one could hope for.


I am less concerned about leadership's response to Mr. Ruppe's 
frustration than I am with the pattern of behavior, spread out 
over many years, that caused that frustration (and the 
frustration of others like Mr. Wilzbach) in the first place. It's 
good to put out fires, but it's even better to avoid starting 
them.

That said, I certainly agree that, regardless of the 
circumstances, Mr. Ruppe bears the ultimate responsibility for 
his own actions.



 Jan 17



prev sibling  parent reply GrimMaple <grimmaple95 gmail.com>  writes:


On Thursday, 18 January 2024 at 01:56:32 UTC, Adam Wilson wrote:

 Professional respect is both earned and revocable. Mr. Ruppe 
 did himself no favors during the November community call (don't 
 know if I can say more than that). Extreme frustration is not, 
 and never can be, an excuse from professional decorum. Mr. 
 Wilzbach handled it much better. IMO, the leadership dealt with 
 Mr. Ruppe about as charitably as one could hope for.


When you try to communicate issues, and instead get told "You are 
free to fork the languge" -- is that the respect we are talking 
about? When you perform a massive amount of work, get ignored, 
and then someone repeatedly refuses to read your code -- is that 
the charitable dealing that a D contributor can expect?

A lot is being said how some people around here are 
_unrespectful_, but I don't always see beheviour that would make 
you respect DLF in the first place. What happens is, DLF people 
are mostly silent with the community, people get frustrated to a 
boiling point, and then everyone on forums just **demands** 
respect. And do nothing to gain said respect.

Respect has to be mutual. One that loses respect because of their 
actions can't just show up and demand to be respected. So, 
instead of demanding respect, start acting in a way that would 
make me respect you.



 Jan 18



  parent reply Guillaume Piolat <first.name gmail.com>  writes:


On Thursday, 18 January 2024 at 09:39:42 UTC, GrimMaple wrote:

 So, instead of demanding respect, start acting in a way that 
 would make me respect you.


It's hard to take the OpenD fork seriously when reading things 
like that.



 Jan 18



 next sibling parent reply Siarhei Siamashka <siarhei.siamashka gmail.com>  writes:


On Thursday, 18 January 2024 at 13:07:45 UTC, Guillaume Piolat 
wrote:

 On Thursday, 18 January 2024 at 09:39:42 UTC, GrimMaple wrote:

 So, instead of demanding respect, start acting in a way that 
 would make me respect you.


 It's hard to take the OpenD fork seriously when reading things 
 like that.


GrimMaple is right. Demanding respect in a rude manner will never 
work. The result is likely to be exactly the opposite.

As for OpenD, I'm still waiting for their first formal release 
before making any judgements. Until then it effectively doesn't 
exist yet.



 Jan 18



  parent  Guillaume Piolat <first.name gmail.com>  writes:


On Thursday, 18 January 2024 at 14:37:33 UTC, Siarhei Siamashka 
wrote:

 Demanding respect in a rude manner will never work. The result 
 is likely to be exactly the opposite.


It worked for you?
https://forum.dlang.org/post/fqhcuecjrvbxuagrwhwa forum.dlang.org



 Jan 18



prev sibling  parent  Hors <q q.com>  writes:


On Thursday, 18 January 2024 at 13:07:45 UTC, Guillaume Piolat 
wrote:

 On Thursday, 18 January 2024 at 09:39:42 UTC, GrimMaple wrote:

 So, instead of demanding respect, start acting in a way that 
 would make me respect you.


 It's hard to take the OpenD fork seriously when reading things 
 like that.


I missed the point where this is related openD. "I don't agree 
with you so your fork is not serious", you just searching for 
something for attack



 Jan 18



prev sibling next sibling parent reply Mike Parker <aldacron gmail.com>  writes:


On Wednesday, 17 January 2024 at 18:28:33 UTC, Paul Backus wrote:


 The problem is not what you did in this specific case; it's the 
 fact that, by the time he submitted the DIP 1036e PR, Adam's 
 relationship with D's leadership had *already* deteriorated so 
 much that he felt only drastic action would get his point 
 across.

 What you (and Walter, and Andrei) could, and should, have done 
 is spent the last 10+ years treating Adam with the respect and 
 professionalism he deserved. What you can, and must, do now is 
 (a) determine why you failed to do so, and (b) make plans to 
 ensure that those failures do not recur in the future (either 
 with Adam, should he return, or with other contributors).


Respect and professionalism is a two-way street. I've seen some 
of these interactions up close and I can tell you it is not in 
anyway 100% Walter/Andrei/Atila's fault. There's plenty of blame 
to go around. Especially in this specific case with Adam. I'm not 
going to into details, but you've seen the same Discord comments 
I've seen, Paul. And you weren't in the two meetings where some 
of us got to see live and in person version. This was going on as 
we were working with him to overcome the issues he had with us. I 
just really take issue with Walter always getting all the blame 
here.

Yes, the DLF needs to find ways to prevent contributors from 
feeling disrespected, ignored, undervalued, and all of that, and 
we need to find ways to help them overcome those feelings if they 
do arise. But please, let's also remember that everyone on the 
DLF team is just as human as the contributors. We deserve the 
same respect and professionalism as everyone else.

There have been multiple occasions when I've gone into the 
Discord server and regretted it, asking myself why I'm even 
bothering to stick around here when the people I'm working for 
keep crapping all over us and the work we're doing. It got to the 
point where I dreaded opening it up. Being called stupid, fools, 
morons, m*fers, and such is the very opposite of a morale booster.

What I would like to see is a commitment from everyone in the D 
community to treat everyone else with professionalism and 
respect. Anyone who is unhappy with a specific decision, process, 
incident, whatever, is welcome to email me and let me know about 
it. I'm happy to set up a meeting with the appropriate people to 
discuss it in person, or facilitate an email conversation with 
them, or whatever is needed to work it out. Too often, people 
don't tell us specifically what their root gripes are until 
they've reached the boiling point, and by then it's too late. So 
please, let us know before that point comes.

And while we're at it, can we please get rid of this "us vs. 
them" mentality? We are all here for the same overarching reason: 
we're enthusiastic about the D programming language. We all want 
it to succeed, and we all want it to help us achieve our ideas 
and our goals. It doesn't matter if you're on the DLF team, an 
employee at one of the D shops, self-employed, or doing this just 
for fun. So let's please keep that in mind when we're interacting 
with each other.



 Jan 17



 next sibling parent reply Paul Backus <snarwin gmail.com>  writes:


On Thursday, 18 January 2024 at 02:51:06 UTC, Mike Parker wrote:

 Respect and professionalism is a two-way street. I've seen some 
 of these interactions up close and I can tell you it is not in 
 anyway 100% Walter/Andrei/Atila's fault. There's plenty of 
 blame to go around. [...]

 Yes, the DLF needs to find ways to prevent contributors from 
 feeling disrespected, ignored, undervalued, and all of that, 
 and we need to find ways to help them overcome those feelings 
 if they do arise. But please, let's also remember that everyone 
 on the DLF team is just as human as the contributors. We 
 deserve the same respect and professionalism as everyone else.


I agree completely. I think the DLF has a great opportunity to 
lead by example here, but regardless, someone else's poor 
behavior is never an excuse for one's own.


 There have been multiple occasions when I've gone into the 
 Discord server and regretted it, asking myself why I'm even 
 bothering to stick around here when the people I'm working for 
 keep crapping all over us and the work we're doing. It got to 
 the point where I dreaded opening it up. Being called stupid, 
 fools, morons, m*fers, and such is the very opposite of a 
 morale booster.


Many open source projects have adopted codes of conduct for their 
community spaces that forbid this sort of behavior. Perhaps D 
would benefit from doing the same.

By the way, this is not just a morale killer for the people being 
called names. It's also discouraging to everyone who makes an 
effort to behave well when they see rude, inflammatory messages 
get rewarded with attention and engagement.


 Anyone who is unhappy with a specific decision, process, 
 incident, whatever, is welcome to email me and let me know 
 about it. I'm happy to set up a meeting with the appropriate 
 people to discuss it in person, or facilitate an email 
 conversation with them, or whatever is needed to work it out. 
 Too often, people don't tell us specifically what their root 
 gripes are until they've reached the boiling point, and by then 
 it's too late. So please, let us know before that point comes.


I think most members of the D community are not even aware that 
this is an option available to them. It would help a lot if the 
DLF could proactively reach out to some of these people, rather 
than passively waiting for them to take the first step.



 Jan 17



 next sibling parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 1/17/2024 8:57 PM, Paul Backus wrote:

 By the way, this is not just a morale killer for the people being called
names. 
 It's also discouraging to everyone who makes an effort to behave well when
they 
 see rude, inflammatory messages get rewarded with attention and engagement.


We do enforce a standard of professional behavior in the forum, and a number of 
posts do get removed. There's a somewhat looser standard when the vitriol is 
directed at me, at my request and in the spirit of letting people say what they 
want, but when it is directed at any other forum member it gets the boot.

We also do not allow cursing, political discussions, or other topics that are 
not about D.

Moderation is under Mike's purview, and his judgements are final and he's got
my 
full support.



 Jan 17



prev sibling  parent reply Dibyendu Majumdar <d.majumdar gmail.com>  writes:


On Thursday, 18 January 2024 at 04:57:36 UTC, Paul Backus wrote:

 On Thursday, 18 January 2024 at 02:51:06 UTC, Mike Parker wrote:

 Respect and professionalism is a two-way street. I've seen 
 some of these interactions up close and I can tell you it is 
 not in anyway 100% Walter/Andrei/Atila's fault. There's plenty 
 of blame to go around. [...]

 Yes, the DLF needs to find ways to prevent contributors from 
 feeling disrespected, ignored, undervalued, and all of that, 
 and we need to find ways to help them overcome those feelings 
 if they do arise. But please, let's also remember that 
 everyone on the DLF team is just as human as the contributors. 
 We deserve the same respect and professionalism as everyone 
 else.


 I agree completely. I think the DLF has a great opportunity to 
 lead by example here, but regardless, someone else's poor 
 behavior is never an excuse for one's own.


As a bystander here I have never observed anything good example 
from the D core team, so not sure what you are talking about. All 
the disrespect, vitriol seems to come from so called 
contributors. If it was me, they would just be kicked out if the 
attacks were personal and disrespectful.



 Jan 18



 next sibling parent  Dibyendu Majumdar <d.majumdar gmail.com>  writes:


On Thursday, 18 January 2024 at 10:58:07 UTC, Dibyendu Majumdar 
wrote:

 As a bystander here I have never observed anything good example 
 from the D core team, so not sure what you are talking about. 
 All the disrespect, vitriol seems to come from so called 
 contributors. If it was me, they would just be kicked out if 
 the attacks were personal and disrespectful.


anything "but" good example, I meant to write.



 Jan 18



prev sibling  parent reply Paul Backus <snarwin gmail.com>  writes:


On Thursday, 18 January 2024 at 10:58:07 UTC, Dibyendu Majumdar 
wrote:

 As a bystander here I have never observed anything good example 
 from the D core team, so not sure what you are talking about. 
 All the disrespect, vitriol seems to come from so called 
 contributors. If it was me, they would just be kicked out if 
 the attacks were personal and disrespectful.


The D core team is always courteous on the forums, but the way 
they handle contributions often displays a lack of respect for 
contributors' time and work. I gave some examples in an earlier 
post. [1]

It is easier to inspire others to be respectful when they can see 
that you are willing to "walk the walk," and not just "talk the 
talk."

All that said, I agree completely that personal attacks should 
not be tolerated.

[1] 
https://forum.dlang.org/post/hmaiefygkvboruvheakv forum.dlang.org



 Jan 18



  parent reply Dibyendu Majumdar <d.majumdar gmail.com>  writes:


On Thursday, 18 January 2024 at 16:07:58 UTC, Paul Backus wrote:

 On Thursday, 18 January 2024 at 10:58:07 UTC, Dibyendu Majumdar 
 wrote:

 As a bystander here I have never observed anything good 
 example from the D core team, so not sure what you are talking 
 about. All the disrespect, vitriol seems to come from so 
 called contributors. If it was me, they would just be kicked 
 out if the attacks were personal and disrespectful.


 The D core team is always courteous on the forums, but the way 
 they handle contributions often displays a lack of respect for 
 contributors' time and work. I gave some examples in an earlier 
 post. [1]


 [1] 
 https://forum.dlang.org/post/hmaiefygkvboruvheakv forum.dlang.org


I had a quick look. To be honest none of those examples show 
disrespect toward contributors. In fact at least 2 of them show 
disrespect toward Walter.
So I still do not see your point here.



 Jan 18



  parent reply Paul Backus <snarwin gmail.com>  writes:


On Thursday, 18 January 2024 at 17:07:52 UTC, Dibyendu Majumdar 
wrote:

 On Thursday, 18 January 2024 at 16:07:58 UTC, Paul Backus wrote:

 On Thursday, 18 January 2024 at 10:58:07 UTC, Dibyendu 
 Majumdar wrote:

 As a bystander here I have never observed anything good 
 example from the D core team, so not sure what you are 
 talking about. All the disrespect, vitriol seems to come from 
 so called contributors. If it was me, they would just be 
 kicked out if the attacks were personal and disrespectful.


 The D core team is always courteous on the forums, but the way 
 they handle contributions often displays a lack of respect for 
 contributors' time and work. I gave some examples in an 
 earlier post. [1]


 [1] 
 https://forum.dlang.org/post/hmaiefygkvboruvheakv forum.dlang.org


 I had a quick look. To be honest none of those examples show 
 disrespect toward contributors. In fact at least 2 of them show 
 disrespect toward Walter.
 So I still do not see your point here.


When someone submits a contribution, and you make them wait for 
weeks or months before you even acknowledge their work, the 
message you are sending is that their work is not important and 
their time is not valuable.

When someone shares their ideas, and you dismiss them without 
even attempting to reach a common understanding, the message you 
are sending is that their ideas are not worth listening to.

When you require others to follow rules and processes, but exempt 
yourself from them, the message you are sending is that you do 
not view those people as your equals.

No matter how polite you are, if you treat people like their work 
is not important, their time is not valuable, their ideas are not 
worth listening to, and they are not your equals, then you are 
not treating them with respect.



 Jan 18



 next sibling parent  Dibyendu Majumdar <d.majumdar gmail.com>  writes:


On Thursday, 18 January 2024 at 18:43:42 UTC, Paul Backus wrote:

 When someone submits a contribution, and you make them wait for 
 weeks or months before you even acknowledge their work, the 
 message you are sending is that their work is not important and 
 their time is not valuable.

 When someone shares their ideas, and you dismiss them without 
 even attempting to reach a common understanding, the message 
 you are sending is that their ideas are not worth listening to.

 When you require others to follow rules and processes, but 
 exempt yourself from them, the message you are sending is that 
 you do not view those people as your equals.

 No matter how polite you are, if you treat people like their 
 work is not important, their time is not valuable, their ideas 
 are not worth listening to, and they are not your equals, then 
 you are not treating them with respect.


Hmm, my reactions are:

* You have to live in the real world. Even in paid work, your PR 
can languish for ages, and sometimes never get merged.
* It is not because people don't respect you - the more mundane 
reason is they haven't got the bandwidth, and you didn't make it 
easy.
* I dread looking at complex PRs myself.
* If I want my changes to go through it is up to me to make it as 
easy to consume as possible. This means I may need to break it up 
into palatable steps, document thoroughly, do in-person or zoom 
walk through of the changes; understand concerns, and address 
them.

This is how things work everywhere.

Secondly - of course you are not equal. The language has 
designated leads, you are not and cannot be equal to them; they 
have a final say.



 Jan 18



prev sibling  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 1/18/2024 10:43 AM, Paul Backus wrote:

 When someone submits a contribution, and you make them wait for weeks or
months 
 before you even acknowledge their work, the message you are sending is that 
 their work is not important and their time is not valuable.


Since these three examples have come up repeatedly, I will add some context.

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

That was submitted Oct 20. Discussion about it had gone on in the n.g. for 
years, which I participated in heavily.


 When someone shares their ideas, and you dismiss them without even attempting
to 
 reach a common understanding, the message you are sending is that their ideas 
 are not worth listening to.


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

Heated discussion has gone on about that issue for years, including at DConf.
Also, https://github.com/dlang/dmd/pull/12828#issuecomment-875455810



 When you require others to follow rules and processes, but exempt yourself
from 
 them, the message you are sending is that you do not view those people as your 
 equals.


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

ImportC is not a language change, and so did not require a DIP. It was not 
pulled by myself, either. You could think of it as simply integration of 
existing tools we were already using. The 3 tools that convert C code to D
code, 
  htod, DStep, and dpp, showed the need for it. It had no impact on anyone who 
wasn't interested in it. We also do not require DIPs for bug fixes, internal 
improvements to the compiler, better code generation, adding things like 
generating C++ headers from D code, etc.

And sure, ImportC met with a lot of skepticism (Adam called it "completely 
useless" https://github.com/dlang/dmd/pull/12507#issuecomment-835915214). Over 
time, it has found its legs and audience. A good proxy for how useful a feature 
is is the quantity of bugzilla issues submitted, and ImportC has had a lot of 
them! (317 submitted, 274 resolved)



 No matter how polite you are, if you treat people like their work is not 
 important, their time is not valuable, their ideas are not worth listening to, 
 and they are not your equals, then you are not treating them with respect.


I agree completely. I also agree that there are instances where I do not live
up 
to those ideals, and need to do better. A better example would be when I added 
user defined attributes over 10 years ago (the result of which the DIP process 
was initiated).



 Jan 19



  parent reply FairEnough <FairEnough gmail.com>  writes:


On Friday, 19 January 2024 at 15:05:28 UTC, Walter Bright wrote:

 ..
 ImportC is not a language change, and so did not require a DIP. 
 ... It had no impact on anyone who wasn't interested in it.
 ...
 ...
 ... A good proxy for how useful a feature is is the quantity of 
 bugzilla issues submitted, and ImportC has had a lot of them! 
 (317 submitted, 274 resolved)


A feature pulled in, essentially without any community 
involvement at the time, has resulted in 317+ bugs being 
summitted, and in addition, peoples time (perhaps mostly yours) 
spent resolving at least 274 of them.

And you're justification is.. "ImportC is not a language change, 
and so did not require a DIP."

As a developer in the team at my business, if you had done this, 
then you would have been promptly shown the door.

btw. None of the above is a comment about the usefulness of 
ImportC, or not. It's about the impact of change that was never 
presented to the community before it got pulled.

And those that pulled it are as much to blame.

Would such a thing still occur today? (that is a question I don't 
know the answer to).



 Jan 27



 next sibling parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 1/27/2024 8:20 PM, FairEnough wrote:

 A feature pulled in, essentially without any community involvement at the
time, 
 has resulted in 317+ bugs being summitted, and in addition, peoples time 
 (perhaps mostly yours) spent resolving at least 274 of them.


Those issues were about ImportC, not the rest of the compiler. As compilers go, 
this is a remarkably small number.

As for the time, it is mine to spend as I see fit. Nobody is paying me.



 And you're justification is.. "ImportC is not a language change, and so did
not 
 require a DIP."


Phobos additions don't require a DIP. Code gen improvements do not. Dub does 
not. C++ header file generation did not. Druntime changes do not. Build system 
does not. Infrastructure does not. Web site changes do not. And so on. Only 
language changes involve a DIP.



 As a developer in the team at my business, if you had done this, then you
would 
 have been promptly shown the door.


I've done bootleg projects at the companies I've worked at. They were all 
eventually mainlined into the official products.



 btw. None of the above is a comment about the usefulness of ImportC, or not.


It's fair to consider the result. ImportC elicited more or less no interest
from 
anybody. I expected that. Over time, though, its detractors who have tried it 
have found it to be a game-changing time saver. ImportC is a huge win for D.

I've implemented a C compiler before, and knew ImportC was going to work. In 
fact, it worked much better than I anticipated.



 It's about the impact of change that was never presented to the community
before 
 it got pulled.


As a proposal, it was not. As a prototype, it was, it just was pulled shortly 
thereafter.



 And those that pulled it are as much to blame.


The fellow that pulled it, Atila, is the author of dpp, a program to import C 
headers to D. Atila understood the potential of ImportC, probably better than 
anyone else.



 Would such a thing still occur today? (that is a question I don't know the 
 answer to).


I thought many times about doing an ImportC++, but ran away screaming. Maybe 
ImportCwithClasses :-)



 Jan 27



 next sibling parent  Daniel N <no public.email>  writes:


On Sunday, 28 January 2024 at 05:29:54 UTC, Walter Bright wrote:

 I thought many times about doing an ImportC++, but ran away 
 screaming. Maybe ImportCwithClasses :-)


One funny thing... C doesn't even need classes. It only needs 
UFCS.



 Jan 28



prev sibling next sibling parent reply ryuukk_ <ryuukk.dev gmail.com>  writes:


On Sunday, 28 January 2024 at 05:29:54 UTC, Walter Bright wrote:

 On 1/27/2024 8:20 PM, FairEnough wrote:

 A feature pulled in, essentially without any community 
 involvement at the time, has resulted in 317+ bugs being 
 summitted, and in addition, peoples time (perhaps mostly 
 yours) spent resolving at least 274 of them.


 Those issues were about ImportC, not the rest of the compiler. 
 As compilers go, this is a remarkably small number.

 As for the time, it is mine to spend as I see fit. Nobody is 
 paying me.



 And you're justification is.. "ImportC is not a language 
 change, and so did not require a DIP."


 Phobos additions don't require a DIP. Code gen improvements do 
 not. Dub does not. C++ header file generation did not. Druntime 
 changes do not. Build system does not. Infrastructure does not. 
 Web site changes do not. And so on. Only language changes 
 involve a DIP.



 As a developer in the team at my business, if you had done 
 this, then you would have been promptly shown the door.


 I've done bootleg projects at the companies I've worked at. 
 They were all eventually mainlined into the official products.



 btw. None of the above is a comment about the usefulness of 
 ImportC, or not.


 It's fair to consider the result. ImportC elicited more or less 
 no interest from anybody. I expected that. Over time, though, 
 its detractors who have tried it have found it to be a 
 game-changing time saver. ImportC is a huge win for D.

 I've implemented a C compiler before, and knew ImportC was 
 going to work. In fact, it worked much better than I 
 anticipated.



 It's about the impact of change that was never presented to 
 the community before it got pulled.


 As a proposal, it was not. As a prototype, it was, it just was 
 pulled shortly thereafter.



 And those that pulled it are as much to blame.


 The fellow that pulled it, Atila, is the author of dpp, a 
 program to import C headers to D. Atila understood the 
 potential of ImportC, probably better than anyone else.



 Would such a thing still occur today? (that is a question I 
 don't know the answer to).


 I thought many times about doing an ImportC++, but ran away 
 screaming. Maybe ImportCwithClasses :-)


And i thank you a lot for ImportC, just last week it saved me a 
ton of time

I needed a voronoi library for some proc-gen, i could have wrote 
it myself but would take me too long, so instead went to C land, 
and simply just imported this library:

https://github.com/JCash/voronoi

```c
#define JC_VORONOI_IMPLEMENTATION
#include "jc_voronoi.h"
```

And in D:

```d
import jc_voronoi;
```

And voila, everything works out of the box



 Jan 28



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 1/28/2024 4:41 AM, ryuukk_ wrote:

 And i thank you a lot for ImportC, just last week it saved me a ton of time
 
 I needed a voronoi library for some proc-gen, i could have wrote it myself but 
 would take me too long, so instead went to C land, and simply just imported
this 
 library:
 
 https://github.com/JCash/voronoi
 
 ```c
 #define JC_VORONOI_IMPLEMENTATION
 #include "jc_voronoi.h"
 ```
 
 And in D:
 
 ```d
 import jc_voronoi;
 ```
 
 And voila, everything works out of the box


Your post makes me happy! Thank you for letting me know this.



 Jan 28



prev sibling next sibling parent reply matheus <matheus gmail.com>  writes:


On Sunday, 28 January 2024 at 05:29:54 UTC, Walter Bright wrote:

 ...


Walter I have a question regarding C, I remember that in the past 
you wrote a paper about a solution for the C Arrays, which would 
be something like storing its size in the first address and 
increment it to be used, and time you want the array size it 
would do something like:
  *(p-1) == size.

Could you please share that paper again?

Thanks in advance,

Matheus.



 Jan 28



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 1/28/2024 1:24 PM, matheus wrote:

 Walter I have a question regarding C, I remember that in the past you wrote a 
 paper about a solution for the C Arrays, which would be something like storing 
 its size in the first address and increment it to be used, and time you want
the 
 array size it would do something like:
   *(p-1) == size.
 
 Could you please share that paper again?


I'm sorry, I don't recall writing such a paper. They're called length-prefixed 
strings, which are useful for some cases but not in the general case because 
they don't support slicing.

I did write a paper about adding D arrays to C:

https://www.digitalmars.com/articles/C-biggest-mistake.html



 Jan 28



prev sibling  parent reply Lance Bachmeier <no spam.net>  writes:


On Sunday, 28 January 2024 at 05:29:54 UTC, Walter Bright wrote:


 It's fair to consider the result. ImportC elicited more or less 
 no interest from anybody. I expected that. Over time, though, 
 its detractors who have tried it have found it to be a 
 game-changing time saver. ImportC is a huge win for D.


I wouldn't say "no interest". This is [what I 
said](https://forum.dlang.org/post/apozoxpxalpdqiysoqak forum.dlang.org):


 This will be incredible. I have a lot of use cases for it. In 
 particular on Windows where linking to DLLs is not fun.


It turns out I was a bit too optimistic. The number of 
dependencies for the typical C project is huge, including things 
like glib, so avoiding them isn't usually possible. I also 
underestimated the widespread use of compiler extensions 
(thankfully this doesn't seem to be much of a problem any longer 
for ImportC).

What has worked surprisingly well is converting C headers to D 
and then using traits to create dynamic bindings at compile time. 
So while it is not what I originally thought it would be, it's 
been a win for me in a different way.



 Jan 28



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 1/28/2024 8:11 PM, Lance Bachmeier wrote:

 On Sunday, 28 January 2024 at 05:29:54 UTC, Walter Bright wrote:
 

 It's fair to consider the result. ImportC elicited more or less no interest 
 from anybody. I expected that. Over time, though, its detractors who have 
 tried it have found it to be a game-changing time saver. ImportC is a huge win 
 for D.


 
 I wouldn't say "no interest". This is [what I 
 said](https://forum.dlang.org/post/apozoxpxalpdqiysoqak forum.dlang.org):


Thanks for reminding me! My mind is like a sieve.



 This will be incredible. I have a lot of use cases for it. In particular on 
 Windows where linking to DLLs is not fun.


 
 It turns out I was a bit too optimistic. The number of dependencies for the 
 typical C project is huge, including things like glib, so avoiding them isn't 
 usually possible. I also underestimated the widespread use of compiler 
 extensions (thankfully this doesn't seem to be much of a problem any longer
for 
 ImportC).


I, too, underestimated the pervasive (and usually quite unnecessary) use of 
bizarro extensions in the C header files. The majority of the problems with 
ImportC were(are) these extensions.



 What has worked surprisingly well is converting C headers to D and then using 
 traits to create dynamic bindings at compile time. So while it is not what I 
 originally thought it would be, it's been a win for me in a different way.


You and Adam Wilson! An unanticipated use, for sure.



 Jan 28



  parent reply max haughton <maxhaton gmail.com>  writes:


On Monday, 29 January 2024 at 06:21:00 UTC, Walter Bright wrote:

 On 1/28/2024 8:11 PM, Lance Bachmeier wrote:

 On Sunday, 28 January 2024 at 05:29:54 UTC, Walter Bright 
 wrote:
 

 It's fair to consider the result. ImportC elicited more or 
 less no interest from anybody. I expected that. Over time, 
 though, its detractors who have tried it have found it to be 
 a game-changing time saver. ImportC is a huge win for D.


 
 I wouldn't say "no interest". This is [what I 
 said](https://forum.dlang.org/post/apozoxpxalpdqiysoqak forum.dlang.org):


 Thanks for reminding me! My mind is like a sieve.



 This will be incredible. I have a lot of use cases for it. In 
 particular on Windows where linking to DLLs is not fun.


 
 It turns out I was a bit too optimistic. The number of 
 dependencies for the typical C project is huge, including 
 things like glib, so avoiding them isn't usually possible. I 
 also underestimated the widespread use of compiler extensions 
 (thankfully this doesn't seem to be much of a problem any 
 longer for ImportC).


 I, too, underestimated the pervasive (and usually quite 
 unnecessary) use of bizarro extensions in the C header files. 
 The majority of the problems with ImportC were(are) these 
 extensions.


Surely you of all people would know that? I was one of the first 
people (that I'm aware of at least) to build and play with 
ImportC (i.e. slightly prior to it being announced) and it 
immediately blew up (even after preprocessing) on some GNU 
headers -- the trend wasn't hard to see.


 What has worked surprisingly well is converting C headers to D 
 and then using traits to create dynamic bindings at compile 
 time. So while it is not what I originally thought it would 
 be, it's been a win for me in a different way.


 You and Adam Wilson! An unanticipated use, for sure.


So what dstep has been doing for years? The value of ImportC is 
in importing c, i.e. thats the thing that the others can't do. 
Even then I think the lack of tools for doing it on the fly as 
part of a build with (say) dub does reveal that the demand is not 
as great as some think. The language is better with it, 
obviously, but I'm genuinely not sure if the strategic investment 
has paid off i.e. it's still in large viewed as a toy / solution 
for yesterday's problem industrially at least (I think we 
*switched* to using it for some bits and pieces recently it must 
be said but it didn't enable anything new).

That and the binding generation is probably not as good as what 
you can do with DStep because it works with a higher level and 
frankly much more modern AST from a real C compiler i.e. more 
info to play with, and info that hasn't potentially been through 
a bunch of D semantic passes - which does mean that you can 
potentially do ExportD, in fairness.



 Jan 29



 next sibling parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 1/29/2024 5:59 PM, max haughton wrote:

 Surely you of all people would know that? I was one of the first people (that 
 I'm aware of at least) to build and play with ImportC (i.e. slightly prior to
it 
 being announced) and it immediately blew up (even after preprocessing) on some 
 GNU headers -- the trend wasn't hard to see.


My priority was compiling Standard C, not C extensions. I assumed that the gnu
C 
headers would at least try to stick with Standard C for the Standard C header 
files. Oops!

To add more complication, the different Posix versions had dramatically 
different Standard C header files, using different extensions.


 What has worked surprisingly well is converting C headers to D and then using 
 traits to create dynamic bindings at compile time. So while it is not what I 
 originally thought it would be, it's been a win for me in a different way.


 You and Adam Wilson! An unanticipated use, for sure.


 
 So what dstep has been doing for years?


As has htod that I wrote, and dpp that Atila wrote.


 The value of ImportC is in importing c, 
 i.e. thats the thing that the others can't do. Even then I think the lack of 
 tools for doing it on the fly as part of a build with (say) dub does reveal
that 
 the demand is not as great as some think. The language is better with it, 
 obviously, but I'm genuinely not sure if the strategic investment has paid off 
 i.e. it's still in large viewed as a toy / solution for yesterday's problem 
 industrially at least (I think we *switched* to using it for some bits and 
 pieces recently it must be said but it didn't enable anything new).
 
 That and the binding generation is probably not as good as what you can do
with 
 DStep because it works with a higher level and frankly much more modern AST
from 
 a real C compiler i.e. more info to play with, and info that hasn't
potentially 
 been through a bunch of D semantic passes - which does mean that you can 
 potentially do ExportD, in fairness.


ImportC is a real C compiler. It doesn't need D to compile, link, and run C 
programs. It isn't, however, a clone of gcc, clang, or msvc.

The .di code generation happens before semantic analysis, not after.

What info to play with is it missing?

Bottom line - if Dstep works for your purposes, great! Use it!



 Jan 29



prev sibling next sibling parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 1/29/2024 5:59 PM, max haughton wrote:

 I was one of the first people (that 
 I'm aware of at least) to build and play with ImportC (i.e. slightly prior to
it 
 being announced) and it immediately blew up (even after preprocessing) on some 
 GNU headers -- the trend wasn't hard to see.


Yes, you were very helpful it providing excellent bug reports in the early daze 
of ImportC. Thank you!



 Jan 29



prev sibling  parent reply bachmeier <no spam.net>  writes:


On Tuesday, 30 January 2024 at 01:59:47 UTC, max haughton wrote:


 So what dstep has been doing for years?


Not only that, but it does work well for that purpose, and it's 
baked into the compiler.


 The value of ImportC is in importing c, i.e. thats the thing 
 that the others can't do.


It works well for C code without a ton of dependencies. It can 
also be used to compile C functions that aren't exported from a 
library, or to modify parts of a C library without having to 
maintain your own fork.



 Jan 29



 next sibling parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 1/29/2024 8:02 PM, bachmeier wrote:

 Not only that, but it does work well for that purpose, and it's baked into the 
 compiler.


It's kinda the same thing as Ddoc and unittests. Building things into the 
compiler is transformative.

Heck, once C acquired an inline assembler, I stopped using MASM. Same thing.



 Jan 29



prev sibling  parent reply Paolo Invernizzi <paolo.invernizzi gmail.com>  writes:


On Tuesday, 30 January 2024 at 04:02:30 UTC, bachmeier wrote:

 On Tuesday, 30 January 2024 at 01:59:47 UTC, max haughton wrote:


 So what dstep has been doing for years?


 Not only that, but it does work well for that purpose, and it's 
 baked into the compiler.


 The value of ImportC is in importing c, i.e. thats the thing 
 that the others can't do.


 It works well for C code without a ton of dependencies. It can 
 also be used to compile C functions that aren't exported from a 
 library, or to modify parts of a C library without having to 
 maintain your own fork.


I'm just wondering how good it is to perform CTFE on C code ... 
humm
We are using a custom sql parser, imagine being able to use this 
[1] instead ... at compile time obviously.

[1] https://github.com/pganalyze/libpg_query

/P



 Jan 30



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 1/30/2024 12:24 AM, Paolo Invernizzi wrote:

 I'm just wondering how good it is to perform CTFE on C code ... humm
 We are using a custom sql parser, imagine being able to use this [1] instead
... 
 at compile time obviously.


CTFE works just fine on ImportC code !!

I use it to speed up tests in the ImportC test suite. No need to build an 
executable for many of the semantic tests.



 Jan 30



prev sibling  parent reply Dibyendu Majumdar <d.majumdar gmail.com>  writes:


On Sunday, 28 January 2024 at 04:20:12 UTC, FairEnough wrote:

 On Friday, 19 January 2024 at 15:05:28 UTC, Walter Bright wrote:

 ..
 ImportC is not a language change, and so did not require a 
 DIP. ... It had no impact on anyone who wasn't interested in 
 it.
 ...
 ...
 ... A good proxy for how useful a feature is is the quantity 
 of bugzilla issues submitted, and ImportC has had a lot of 
 them! (317 submitted, 274 resolved)


 A feature pulled in, essentially without any community 
 involvement at the time, has resulted in 317+ bugs being 
 summitted, and in addition, peoples time (perhaps mostly yours) 
 spent resolving at least 274 of them.

 And you're justification is.. "ImportC is not a language 
 change, and so did not require a DIP."

 As a developer in the team at my business, if you had done 
 this, then you would have been promptly shown the door.


But this where you get it wrong. This is not a business. The 
thing about D is that everyone works on what they want to work 
on. and its perfectly valid for Walter to work on whatever 
motivates him.

It took me a while to grasp this about the D eco-system, but its 
key to getting your expectations right. If you want a business 
like focused approach that managed top-down, this is not it.



 Jan 28



 next sibling parent reply Dibyendu Majumdar <d.majumdar gmail.com>  writes:


On Sunday, 28 January 2024 at 11:23:45 UTC, Dibyendu Majumdar 
wrote:


 But this where you get it wrong. This is not a business. The 
 thing about D is that everyone works on what they want to work 
 on. and its perfectly valid for Walter to work on whatever 
 motivates him.


I don't know if I am right but part of the motivation of import C 
seems to have been competition - Zig added the ability to compile 
C. It seems the idea of import C came up after and maybe as a 
consequence of this.



 Jan 28



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 1/28/2024 3:27 AM, Dibyendu Majumdar wrote:

 I don't know if I am right but part of the motivation of import C seems to
have 
 been competition - Zig added the ability to compile C. It seems the idea of 
 import C came up after and maybe as a consequence of this.


I didn't know Zig did that until after I did ImportC.



 Jan 28



 next sibling parent reply Don Allen <donaldcallen gmail.com>  writes:


On Sunday, 28 January 2024 at 17:04:02 UTC, Walter Bright wrote:

 On 1/28/2024 3:27 AM, Dibyendu Majumdar wrote:

 I don't know if I am right but part of the motivation of 
 import C seems to have been competition - Zig added the 
 ability to compile C. It seems the idea of import C came up 
 after and maybe as a consequence of this.


 I didn't know Zig did that until after I did ImportC.


Zig also has the ability to translate C headers into Zig. The 
result is very similar to ImportC. I believe I mentioned this to 
you when ImportC first became available.

I think this is an important capability for both languages. Added 
to the ability to call C libraries directly, it makes direct 
access, without binding libraries, to C libraries possible. I 
think your decision to implement ImportC was a good one.

I've done quite a bit of gtk3 work in Rust. The Rust gtk "crate" 
is insanely complex and poorly documented (sometimes even 
inaccurate, where they generate the documentation using snippets 
from the original gtk3 docs, sometimes including 
memory-management things that are not necessary in Rust), unlike 
gtk3 itself. I much prefer working directly with gtk3 in D. I did 
the D work before ImportC was available, so wrote my own D 
function prototypes. Even that was preferable to wrestling with 
the Rust "crate" and I'm sure ImportC would have made the job a 
lot easier, if it is up to dealing with the gtk header files. I 
have tried ImportC with sqlite and that works just fine.



 Jan 28



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 1/28/2024 7:35 PM, Don Allen wrote:

 Zig also has the ability to translate C headers into Zig. The result is very 
 similar to ImportC. I believe I mentioned this to you when ImportC first
became 
 available.


You probably did.



 I think this is an important capability for both languages. Added to the
ability 
 to call C libraries directly, it makes direct access, without binding
libraries, 
 to C libraries possible. I think your decision to implement ImportC was a good
one.
 
 I've done quite a bit of gtk3 work in Rust. The Rust gtk "crate" is insanely 
 complex and poorly documented (sometimes even inaccurate, where they generate 
 the documentation using snippets from the original gtk3 docs, sometimes 
 including memory-management things that are not necessary in Rust), unlike
gtk3 
 itself. I much prefer working directly with gtk3 in D. I did the D work before 
 ImportC was available, so wrote my own D function prototypes. Even that was 
 preferable to wrestling with the Rust "crate" and I'm sure ImportC would have 
 made the job a lot easier, if it is up to dealing with the gtk header files. I 
 have tried ImportC with sqlite and that works just fine.


I'm glad it's working for you!

D can actually translate C to D, as well. Just add the switch for .di file 
generation, and the C code will be emitted as D! Adam Wilson prefers to use it 
this way rather than keep importing the .h files.

I warned Adam that this was imperfect, as C semantics don't exactly line up
with 
D semantics. But he's well aware of that, and it isn't a problem for his work.



 Jan 28



prev sibling  parent reply Dibyendu Majumdar <d.majumdar gmail.com>  writes:


On Sunday, 28 January 2024 at 17:04:02 UTC, Walter Bright wrote:

 On 1/28/2024 3:27 AM, Dibyendu Majumdar wrote:

 I don't know if I am right but part of the motivation of 
 import C seems to have been competition - Zig added the 
 ability to compile C. It seems the idea of import C came up 
 after and maybe as a consequence of this.


 I didn't know Zig did that until after I did ImportC.


When did you start on importC?

https://forum.dlang.org/thread/yocvibzernkchgsbcpyb forum.dlang.org



 Jan 29



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 1/29/2024 1:34 PM, Dibyendu Majumdar wrote:

 On Sunday, 28 January 2024 at 17:04:02 UTC, Walter Bright wrote:

 On 1/28/2024 3:27 AM, Dibyendu Majumdar wrote:

 I don't know if I am right but part of the motivation of import C seems to 
 have been competition - Zig added the ability to compile C. It seems the idea 
 of import C came up after and maybe as a consequence of this.


 I didn't know Zig did that until after I did ImportC.


 
 When did you start on importC?
 
 https://forum.dlang.org/thread/yocvibzernkchgsbcpyb forum.dlang.org


That post was Dec 3, 2020. The PR for ImportC was May 9, 2021, about 5 months 
later. When did I start ImportC? I don't recall. I don't recall reading that 
thread, either, I don't read all the messages, and am generally not interested 
in detailed comparisons of D with other languages (as it is an endless
timesink).

I also was never sure if Zig could actually import C files, or was just able to 
fork a C compiler and link to the result. But this clears it up:

```C
const c =  cImport( cInclude("soundio/soundio.h"));
```

https://ziglang.org/learn/overview/#integration-with-c-libraries-without-ffibindings

D's syntax is better:

```d
import soundio;
```

ImportC grew out of my discussions with Atila about dpp.



 Jan 29



 next sibling parent reply max haughton <maxhaton gmail.com>  writes:


On Tuesday, 30 January 2024 at 00:57:31 UTC, Walter Bright wrote:


 https://ziglang.org/learn/overview/#integration-with-c-libraries-without-ffibindings

 D's syntax is better:


Well the syntax is cleaner but has the potential to be ambiguous 
both with .d files and the usual <> vs "" stuff.



 Jan 29



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 1/29/2024 5:45 PM, max haughton wrote:

 Well the syntax is cleaner but has the potential to be ambiguous both with .d 
 files and the usual <> vs "" stuff.


Right. Putting .c and .d files with the same name in the same directory is not 
going to work well. The fix is easy and permanent - rename the .d or the .c
file.



 Jan 29



  parent reply Steven Schveighoffer <schveiguy gmail.com>  writes:


On Tuesday, 30 January 2024 at 04:00:48 UTC, Walter Bright wrote:

 On 1/29/2024 5:45 PM, max haughton wrote:

 Well the syntax is cleaner but has the potential to be 
 ambiguous both with .d files and the usual <> vs "" stuff.


 Right. Putting .c and .d files with the same name in the same 
 directory is not going to work well. The fix is easy and 
 permanent - rename the .d or the .c file.


Or in the same import path. This is what bit me -- my C files 
were not in the same directory, but in a similarly named 
directory. I ended up having to rename the directory to prevent 
the compiler from finding them.

I also think the syntax can be clean without being ambiguous:

```d
// import(C) soundio; // sadly not available because import 
expressions
import!C soundio;
```

-Steve



 Jan 31



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 1/31/2024 1:22 PM, Steven Schveighoffer wrote:

 I also think the syntax can be clean without being ambiguous:
 
 ```d
 // import(C) soundio; // sadly not available because import expressions
 import!C soundio;
 ```



The rationale for not having a special syntax for importing C files is the 
importer should not have to know what language the import comes from. That 
information should not "leak" into the importer's code. The point is seamless 
integration.

Analogously, if one gets from a .di file import:

```
int foo();
```

it should not matter what language foo() is implemented in. The caller should 
not need to know. Having to organize the file names and paths so this works is
a 
very small price to pay for this abstraction.

Besides, if you have these files in your folder:

foo.c

foo.d

what is the maintainer looking at the files going to think? Which one is 
incorporated into the code? foo.c? foo.d? both? neither? It's a sloppy
practice, 
not some vital thing to support. One can name files as one pleases, organize 
them into sensible folders, etc., all part of doing a good job as a programmer.



 Feb 01



 next sibling parent  Steven Schveighoffer <schveiguy gmail.com>  writes:


On Thursday, 1 February 2024 at 17:49:42 UTC, Walter Bright wrote:

 On 1/31/2024 1:22 PM, Steven Schveighoffer wrote:

 I also think the syntax can be clean without being ambiguous:
 
 ```d
 // import(C) soundio; // sadly not available because import 
 expressions
 import!C soundio;
 ```



 The rationale for not having a special syntax for importing C 
 files is the importer should not have to know what language the 
 import comes from. That information should not "leak" into the 
 importer's code. The point is seamless integration.

 Analogously, if one gets from a .di file import:

 ```
 int foo();
 ```

 it should not matter what language foo() is implemented in. The 
 caller should not need to know. Having to organize the file 
 names and paths so this works is a very small price to pay for 
 this abstraction.


This means you are changing the language based on the environment 
and on the whims of the compiler implementer. It's not a small 
price when it happens. In an ideal situation, where you control 
all files and environmental conditions, it could be fine. But we 
all live in the real world.


 Besides, if you have these files in your folder:

 foo.c

 foo.d

 what is the maintainer looking at the files going to think? 
 Which one is incorporated into the code? foo.c? foo.d? both? 
 neither? It's a sloppy practice, not some vital thing to 
 support. One can name files as one pleases, organize them into 
 sensible folders, etc., all part of doing a good job as a 
 programmer.


In my case, it was:

raylib/rtextures.c

source/raylib/rtextures.d

And because D always looks in the current directory first, 
importing `raylib.rtextures` means the C file even though it 
wasn't intended to be part of the source code.

What was I intending? Not to have the C files participate at all, 
after all, they aren't in the source directory. My solution is to 
rename the C-containing folder to `raylibc` (which still could 
technically be imported, but I'm not sure how to fix that).

https://github.com/schveiguy/draylib/commit/9b04409fc3bda331d0a03583b2861552ffcaab04

In the general case, there are easily situations where C files 
might be in places that you need to specify an import path, where 
you *only* want one C file, but other C files that you *don't* 
want happen to conflict import-wise with D files in completely 
unrelated directories. It's not just the obviously wrong 
situation of putting a C and D file in the same directory.

D has this problem even with other D files. This is why I always 
recommend putting all your library files into a uniquely-named 
package. But with C files it's even worse, because C environments 
are not constructed with the import rules of D in mind.

-Steve



 Feb 01



prev sibling  parent  Jonathan M Davis <newsgroup.d jmdavisprog.com>  writes:


On Thursday, February 1, 2024 10:49:42 AM MST Walter Bright via Digitalmars-d 
wrote:

 On 1/31/2024 1:22 PM, Steven Schveighoffer wrote:

 I also think the syntax can be clean without being ambiguous:

 ```d
 // import(C) soundio; // sadly not available because import expressions
 import!C soundio;
 ```


 The rationale for not having a special syntax for importing C files is the
 importer should not have to know what language the import comes from. That
 information should not "leak" into the importer's code. The point is
 seamless integration.

 Analogously, if one gets from a .di file import:

 ```
 int foo();
 ```

 it should not matter what language foo() is implemented in. The caller
 should not need to know. Having to organize the file names and paths so
 this works is a very small price to pay for this abstraction.

 Besides, if you have these files in your folder:

 foo.c

 foo.d

 what is the maintainer looking at the files going to think? Which one is
 incorporated into the code? foo.c? foo.d? both? neither? It's a sloppy
 practice, not some vital thing to support. One can name files as one
 pleases, organize them into sensible folders, etc., all part of doing a
 good job as a programmer.


Well, I would point out that if import C had its own syntax, anyone who
wanted it to be invisible as to whether importC was involved or not could
just stick the importC import inside of another module and make the importC
import public. Then code could import the D module without knowing or caring
whether importC was involved or not - and when someone did want to make it
clear that that's what's going on, they could just use the importC import
directly.

While I agree that you often don't want to have to care about which language
defines something, prior to importC, you could at least rely on the fact
that what you were importing was D code even if they were just declarations.
And it's certainly my gut reaction that I very much want to know when I'm
importing C code and not D code. Whether the module being imported is
actually a D module or a C file changes what I have to look for when looking
up the file to see what's in it, and hiding the fact that it's a C file just
makes that harder. And in general, I want to know when stuff is extern(C),
or extern(C++), or extern(D), or whatever because that does affect how it
should be used.

So, personally, I'm inclined to think that making importC imports distinct
from normal D imports would reduce the number of problems involved rather
than increase them, but it's also true that I haven't done anything with
importC yet (the one time I tried, I couldn't figure out how to do it in the
time that I had). So, I haven't had to actually deal with the pros or cons
of how it currently works.

- Jonathan M Davis



 Feb 06



prev sibling  parent reply Dibyendu Majumdar <d.majumdar gmail.com>  writes:


On Tuesday, 30 January 2024 at 00:57:31 UTC, Walter Bright wrote:

 On 1/29/2024 1:34 PM, Dibyendu Majumdar wrote:

 On Sunday, 28 January 2024 at 17:04:02 UTC, Walter Bright 
 wrote:

 On 1/28/2024 3:27 AM, Dibyendu Majumdar wrote:

 I don't know if I am right but part of the motivation of 
 import C seems to have been competition - Zig added the 
 ability to compile C. It seems the idea of import C came up 
 after and maybe as a consequence of this.


 I didn't know Zig did that until after I did ImportC.


 
 When did you start on importC?
 
 https://forum.dlang.org/thread/yocvibzernkchgsbcpyb forum.dlang.org


 That post was Dec 3, 2020. The PR for ImportC was May 9, 2021, 
 about 5 months later. When did I start ImportC? I don't recall. 
 I don't recall reading that thread, either, I don't read all 
 the messages, and am generally not interested in detailed 
 comparisons of D with other languages (as it is an endless 
 timesink).

 ImportC grew out of my discussions with Atila about dpp.



It doesn't really matter I guess, but its interesting that the 
discussion I pointed to actually suggested importC and dpp was 
mentioned, so it seems either you or Atila saw that thread. Maybe 
a delayed subconscious reaction.

I certainly thought at the time that importC was a reaction to 
Zig doing it. I recall vaguely you started work on it after that 
thread.



 Jan 30



  parent reply bachmeier <no spam.net>  writes:


On Tuesday, 30 January 2024 at 13:06:08 UTC, Dibyendu Majumdar 
wrote:


 I certainly thought at the time that importC was a reaction to 
 Zig doing it. I recall vaguely you started work on it after 
 that thread.


It's not full ImportC, but I remember Walter was talking about 
adding C header translation to the compiler [well before 
that](https://forum.dlang.org/post/p59jdq$2ttu$1 digitalmars.com), and
apparently it was an old idea by then:


 I have thought about building this into D many times, 
 especially since the Digital Mars C compiler is now available 
 since it is Boost licensed.


I don't think it would have been a big leap from that to 
compiling arbitrary code (the implementation would, but not the 
idea). Jacob Carlborg embedded dstep in the compiler in 2013:

https://forum.dlang.org/post/ks3kir$1ubq$1 digitalmars.com

Note Dicebot's comment:


 While this a relatively common request


All this is to say that the idea was floating around before Zig 
existed. It's the implementation that's important.



 Jan 30



  parent reply Dibyendu Majumdar <d.majumdar gmail.com>  writes:


On Tuesday, 30 January 2024 at 14:27:18 UTC, bachmeier wrote:


 It's not full ImportC, but I remember Walter was talking about 
 adding C header translation to the compiler [well before 
 that](https://forum.dlang.org/post/p59jdq$2ttu$1 digitalmars.com), and
apparently it was an old idea by then:


The idea of generating automatic bindings to declarations in 
header files may have been old, but the idea of compiling actual 
C programs appears to have come from Zig:

https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html



 Jan 30



 next sibling parent  Sergey <kornburn yandex.ru>  writes:


On Tuesday, 30 January 2024 at 15:17:31 UTC, Dibyendu Majumdar 
wrote:

 The idea of generating automatic bindings to declarations in 
 header files may have been old, but the idea of compiling 
 actual C programs appears to have come from Zig:

 https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html


The idea is not new and unique for Zig
3 years before your post 
https://users.rust-lang.org/t/rustcc-a-c-compiler-written-in-rust/14322/4



 Jan 30



prev sibling next sibling parent reply Mike Parker <aldacron gmail.com>  writes:


On Tuesday, 30 January 2024 at 15:17:31 UTC, Dibyendu Majumdar 
wrote:

 On Tuesday, 30 January 2024 at 14:27:18 UTC, bachmeier wrote:


 It's not full ImportC, but I remember Walter was talking about 
 adding C header translation to the compiler [well before 
 that](https://forum.dlang.org/post/p59jdq$2ttu$1 digitalmars.com), and
apparently it was an old idea by then:


 The idea of generating automatic bindings to declarations in 
 header files may have been old, but the idea of compiling 
 actual C programs appears to have come from Zig:

 https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html


There were discussions about the possibility of dmd compiling C 
code several years ago. My search attempts keep turning up way 
too many pages, but this is an old idea in the D community.



 Jan 30



 next sibling parent reply Mike Parker <aldacron gmail.com>  writes:


On Tuesday, 30 January 2024 at 15:36:34 UTC, Mike Parker wrote:

 There were discussions about the possibility of dmd compiling C 
 code several years ago. My search attempts keep turning up way 
 too many pages, but this is an old idea in the D community.


Okay, here's an early discussion. Not exactly the same, but in 
the ballpark:

https://www.digitalmars.com/d/archives/22625.html


 At first pass, I would assume that the C source would be passed 
 without modification into the system's C compiler; the D 
 compiler would then automatically link the C compiler's .o file 
 with the D compiler's .o file.





 Jan 30



  parent reply Mike Parker <aldacron gmail.com>  writes:


On Tuesday, 30 January 2024 at 15:44:28 UTC, Mike Parker wrote:

 On Tuesday, 30 January 2024 at 15:36:34 UTC, Mike Parker wrote:

 There were discussions about the possibility of dmd compiling 
 C code several years ago. My search attempts keep turning up 
 way too many pages, but this is an old idea in the D community.


 Okay, here's an early discussion. Not exactly the same, but in 
 the ballpark:

 https://www.digitalmars.com/d/archives/22625.html


And here's the earliest discussion of an ImportC-style thing that 
I can find (2006):

https://www.digitalmars.com/d/archives/digitalmars/D/35483.html


 Why not enable dmd to "import" C header files directly?


One of the commenters listed this as a point against:


 2. Writers of other D compilers will feel compelled to build in 
 a C compiler so that they can compile such projects.





 Jan 30



 next sibling parent reply jmh530 <john.michael.hall gmail.com>  writes:


On Tuesday, 30 January 2024 at 15:53:50 UTC, Mike Parker wrote:

 On Tuesday, 30 January 2024 at 15:44:28 UTC, Mike Parker wrote:

 On Tuesday, 30 January 2024 at 15:36:34 UTC, Mike Parker wrote:

 [...]


 Okay, here's an early discussion. Not exactly the same, but in 
 the ballpark:

 https://www.digitalmars.com/d/archives/22625.html


 And here's the earliest discussion of an ImportC-style thing 
 that I can find (2006):

 https://www.digitalmars.com/d/archives/digitalmars/D/35483.html


 Why not enable dmd to "import" C header files directly?


 One of the commenters listed this as a point against:


 2. Writers of other D compilers will feel compelled to build 
 in a C compiler so that they can compile such projects.




Does it really matter?



 Jan 30



 next sibling parent  Bruce Carneal <bcarneal gmail.com>  writes:


On Tuesday, 30 January 2024 at 15:58:46 UTC, jmh530 wrote:

 On Tuesday, 30 January 2024 at 15:53:50 UTC, Mike Parker wrote:

 On Tuesday, 30 January 2024 at 15:44:28 UTC, Mike Parker wrote:

 On Tuesday, 30 January 2024 at 15:36:34 UTC, Mike Parker 
 wrote:

 [...]


 Okay, here's an early discussion. Not exactly the same, but 
 in the ballpark:

 https://www.digitalmars.com/d/archives/22625.html


 And here's the earliest discussion of an ImportC-style thing 
 that I can find (2006):

 https://www.digitalmars.com/d/archives/digitalmars/D/35483.html


 Why not enable dmd to "import" C header files directly?


 One of the commenters listed this as a point against:


 2. Writers of other D compilers will feel compelled to build 
 in a C compiler so that they can compile such projects.




 Does it really matter?


The history of programming languages is interesting in itself and 
it's good to acknowledge those making progress.  It's also good 
to adopt/adapt the pioneering work of others.  I'd also note that 
many programmers come to previously discovered good ideas 
independently.

OTOH, I think we've all known people who have made false claims 
in this area.  I'd rather associate with those who don't.

So, yes, I think it matters but I don't see it as a big problem 
within the D community itself.



 Jan 30



prev sibling  parent reply Mike Parker <aldacron gmail.com>  writes:


On Tuesday, 30 January 2024 at 15:58:46 UTC, jmh530 wrote:


 Does it really matter?


Of course not. Just sharing what I found since it came up.



 Jan 30



  parent  Dibyendu Majumdar <d.majumdar gmail.com>  writes:


On Tuesday, 30 January 2024 at 16:27:34 UTC, Mike Parker wrote:

 On Tuesday, 30 January 2024 at 15:58:46 UTC, jmh530 wrote:


 Does it really matter?


 Of course not. Just sharing what I found since it came up.


It doesn't matter as such, but answering competition is a good 
excuse for it :-)



 Jan 30



prev sibling  parent  bachmeier <no spam.net>  writes:


On Tuesday, 30 January 2024 at 15:53:50 UTC, Mike Parker wrote:

 On Tuesday, 30 January 2024 at 15:44:28 UTC, Mike Parker wrote:

 On Tuesday, 30 January 2024 at 15:36:34 UTC, Mike Parker wrote:

 There were discussions about the possibility of dmd compiling 
 C code several years ago. My search attempts keep turning up 
 way too many pages, but this is an old idea in the D 
 community.


 Okay, here's an early discussion. Not exactly the same, but in 
 the ballpark:

 https://www.digitalmars.com/d/archives/22625.html


 And here's the earliest discussion of an ImportC-style thing 
 that I can find (2006):

 https://www.digitalmars.com/d/archives/digitalmars/D/35483.html


 Why not enable dmd to "import" C header files directly?


 One of the commenters listed this as a point against:


 2. Writers of other D compilers will feel compelled to build 
 in a C compiler so that they can compile such projects.




That's a lot earlier than what I found, but my recollection was 
that it had been floating around the whole time I've been using 
D. The idea isn't important for something like this - 
implementation is all that matters.

I attempted to hack a solution like ImportC at one time, with a 
script that would call dstep, a C compiler, and dmd. The 
compilation command was similar to what we have today. That went 
down in flames quickly because dstep couldn't fully translate 
headers.



 Jan 30



prev sibling  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 1/30/2024 7:36 AM, Mike Parker wrote:

 There were discussions about the possibility of dmd compiling C code several 
 years ago. My search attempts keep turning up way too many pages, but this is
an 
 old idea in the D community.


The idea really goes back to C++. The C++ compiler could compile C code.
Wanting 
to make this work for D was always on my mind.



 Jan 30



prev sibling  parent  jmh530 <john.michael.hall gmail.com>  writes:


On Tuesday, 30 January 2024 at 15:17:31 UTC, Dibyendu Majumdar 
wrote:

 On Tuesday, 30 January 2024 at 14:27:18 UTC, bachmeier wrote:


 It's not full ImportC, but I remember Walter was talking about 
 adding C header translation to the compiler [well before 
 that](https://forum.dlang.org/post/p59jdq$2ttu$1 digitalmars.com), and
apparently it was an old idea by then:


 The idea of generating automatic bindings to declarations in 
 header files may have been old, but the idea of compiling 
 actual C programs appears to have come from Zig:

 https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html


Zig did it before D (arguably C++ and Objective C did something 
similar well before Zig). It doesn't really matter if Walter knew 
about what Zig was doing or not. It was a good idea and it's a 
good addition to D at the end of the day.



 Jan 30



prev sibling  parent  FairEnough <FairEnough gmail.com>  writes:


On Sunday, 28 January 2024 at 11:23:45 UTC, Dibyendu Majumdar 
wrote:

 ..
 But this where you get it wrong. This is not a business. The 
 thing about D is that everyone works on what they want to work 
 on. and its perfectly valid for Walter to work on whatever 
 motivates him.

 It took me a while to grasp this about the D eco-system, but 
 its key to getting your expectations right. If you want a 
 business like focused approach that managed top-down, this is 
 not it.


So I am pretty sure I fully understand the concept of opensource 
and also the concept of people volunteering their time to it. I 
don't need lessons in that ;-)

I have assumed, perhaps wrongly, that (at the time of that PR) 
there were other people volunteering their time to the compiler 
as well, besides Walter. In that were true, then a team based 
approach would not be consistent with slipping this PR in, more 
or less without warning.

In any case, as I said, my comment is not about the PR itself, 
but the manner in which it was pulled. Even in an opensource 
project like this, team work remains the key to its success. To 
me, the way the PR found its way into the compiler, suggest 
either no team existed, or team work was not a priority.

I understand that this is just my view, and not necessarily how 
it is. But it's my view that matters to me ;-)



 Jan 28



prev sibling  parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz>  writes:


On 18/01/2024 3:51 PM, Mike Parker wrote:

 And while we're at it, can we please get rid of this "us vs. them" 
 mentality? We are all here for the same overarching reason: we're 
 enthusiastic about the D programming language. We all want it to 
 succeed, and we all want it to help us achieve our ideas and our goals. 
 It doesn't matter if you're on the DLF team, an employee at one of the D 
 shops, self-employed, or doing this just for fun. So let's please keep 
 that in mind when we're interacting with each other.


Part of the problem that allows this to exist is simply because Walter & 
Atila are not where the people are.

Yes Walter is active on the N.G., Atila isn't.

However neither are on Discord, the easiest of live chat methods that we 
have.

It is much harder to call someone a name, if they are responding 
directly to you.

Of course because Walter keeps saying, I don't care if you insult me 
(more or less) on the N.G. its not like us moderators can take action, 
because he has waived an awful lot of the expectation of respect in 
simply stating that.

It is a shame you didn't tell us how this was making you feel in the 
first instance. Once you told us I did I was able to change myself to 
lead changes. But only recently does the worst of the aggressors appear 
to have left.



 Jan 17



 next sibling parent  Guillaume Piolat <first.name gmail.com>  writes:


On Thursday, 18 January 2024 at 06:31:33 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 Of course because Walter keeps saying, I don't care if you 
 insult me (more or less) on the N.G. its not like us moderators 
 can take action, because he has waived an awful lot of the 
 expectation of respect in simply stating that.


+1

Behaviour flows from the top.
It's important to realize a chunk of the newcomers are people, 
for lack of better words, prone to trolling behaviour that may be 
attracted by that lax rules enabled by the top of the hierarchy.

It makes the work of being a moderator in the D community much 
more stressful than people may realize.



 Jan 18



prev sibling  parent  aberba <karabutaworld gmail.com>  writes:


On Thursday, 18 January 2024 at 06:31:33 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 On 18/01/2024 3:51 PM, Mike Parker wrote:

 And while we're at it, can we please get rid of this "us vs. 
 them" mentality? We are all here for the same overarching 
 reason: we're enthusiastic about the D programming language. 
 We all want it to succeed, and we all want it to help us 
 achieve our ideas and our goals. It doesn't matter if you're 
 on the DLF team, an employee at one of the D shops, 
 self-employed, or doing this just for fun. So let's please 
 keep that in mind when we're interacting with each other.


 Part of the problem that allows this to exist is simply because 
 Walter & Atila are not where the people are.

 Yes Walter is active on the N.G., Atila isn't.

 However neither are on Discord, the easiest of live chat 
 methods that we have.


Discord is a huge time sink and unproductive. I doubt the DLF 
folks can deal with it and get anything done. I sometimes wonder 
how you guys manage to get anything else done lol.

On a serious note, I think being active in this forum alone is 
enough. But no pressure.



 Jan 18



prev sibling  parent reply Meta <jared771 gmail.com>  writes:


On Wednesday, 17 January 2024 at 18:28:33 UTC, Paul Backus wrote:

 The problem is not what you did in this specific case; it's the 
 fact that, by the time he submitted the DIP 1036e PR, Adam's 
 relationship with D's leadership had *already* deteriorated so 
 much that he felt only drastic action would get his point 
 across.

 What you (and Walter, and Andrei) could, and should, have done 
 is spent the last 10+ years treating Adam with the respect and 
 professionalism he deserved. What you can, and must, do now is 
 (a) determine why you failed to do so, and (b) make plans to 
 ensure that those failures do not recur in the future (either 
 with Adam, should he return, or with other contributors).


I mean, let's all be brutally real here for a minute. I've been 
in this community since 2012, and I'm familiar with all the 
regulars and even the old regulars who aren't around anymore.

Adam's always been a bit of a prima donna - the lone wolf 
developer type who always wants to do things his own way or not 
at all. If you subscribe to the Jungian personality model, he's 
most likely an INTJ - very emotionally charged and willful, very 
sensitive to issues of status and respect, and notoriously 
difficult to work with.

There's plenty of blame to go around, and ultimately it just 
comes down to a clash of different personalities and outlooks. 
People have wildly different motivations, and different standards 
for what constitutes disrespect, and ways of dealing with it. Not 
to mention varying levels of maturity and social skills.

Sometimes shit just happens and there's not much you can do to 
avoid or fix it.



 Jan 18



  parent reply Paul Backus <snarwin gmail.com>  writes:


On Thursday, 18 January 2024 at 20:26:50 UTC, Meta wrote:

 There's plenty of blame to go around, and ultimately it just 
 comes down to a clash of different personalities and outlooks. 
 People have wildly different motivations, and different 
 standards for what constitutes disrespect, and ways of dealing 
 with it. Not to mention varying levels of maturity and social 
 skills.

 Sometimes shit just happens and there's not much you can do to 
 avoid or fix it.


Yes, that's certainly true.

My intent is not to focus on Adam Ruppe's case specifically, but 
on the broader pattern that also includes former contributors 
like Sebastian Wilzbach, Jonathan Marler, ag0aep6g, Suleyman 
Sahmi (SSoulaimane), etc. When one relationship fails, that's 
unfortunate. When a long string of relationships fail in the same 
way, that's a sign of a deeper problem.

Even if we grant that there was nothing more to be done in Adam's 
case, I think D's approach to contributor relationships is 
leaving a lot of value on the table.



 Jan 18



 next sibling parent  "H. S. Teoh" <hsteoh qfbox.info>  writes:


On Thu, Jan 18, 2024 at 08:51:48PM +0000, Paul Backus via Digitalmars-d wrote:

 On Thursday, 18 January 2024 at 20:26:50 UTC, Meta wrote:


[...]

 My intent is not to focus on Adam Ruppe's case specifically, but on
 the broader pattern that also includes former contributors like
 Sebastian Wilzbach, Jonathan Marler, ag0aep6g, Suleyman Sahmi
 (SSoulaimane), etc. When one relationship fails, that's unfortunate.
 When a long string of relationships fail in the same way, that's a
 sign of a deeper problem.


Exactly.



 Even if we grant that there was nothing more to be done in Adam's
 case, I think D's approach to contributor relationships is leaving a
 lot of value on the table.


Yes, this area definitely needs improving.  We should be keeping active
contributors, not losing them.


T

-- 
Let's not fight disease by killing the patient. -- Sean 'Shaleh' Perry



 Jan 18



prev sibling next sibling parent  zjh <fqbqrr 163.com>  writes:


On Thursday, 18 January 2024 at 20:51:48 UTC, Paul Backus wrote:


 My intent is not to focus on Adam Ruppe's case specifically, 
 but on the broader pattern that also includes former 
 contributors like Sebastian Wilzbach, Jonathan Marler, 
 ag0aep6g, Suleyman Sahmi (SSoulaimane), etc. When one 
 relationship fails, that's unfortunate. When a long string of 
 relationships fail in the same way, that's a sign of a deeper 
 problem.



That's right, what the `community` needs is a constant influx of 
talent, not a constant outflow. The departure of these people is 
a `significant loss` for D!

This is a major failure in `community management`!
If there is continuous loss, then all D users will be victims.
Because D's users are victims, having a `better branch` is not a 
bad thing, and even `more branches` can be established to reduce 
harm.



 Jan 18



prev sibling  parent reply Dukc <ajieskola gmail.com>  writes:


On Thursday, 18 January 2024 at 20:51:48 UTC, Paul Backus wrote:

 Yes, that's certainly true.

 My intent is not to focus on Adam Ruppe's case specifically, 
 but on the broader pattern that also includes former 
 contributors like Sebastian Wilzbach, Jonathan Marler, 
 ag0aep6g, Suleyman Sahmi (SSoulaimane), etc. When one 
 relationship fails, that's unfortunate. When a long string of 
 relationships fail in the same way, that's a sign of a deeper 
 problem.

 Even if we grant that there was nothing more to be done in 
 Adam's case, I think D's approach to contributor relationships 
 is leaving a lot of value on the table.


I get the impression that these kinds of problems are more of a 
rule than an exception in succesful open-source projects though 
(by succesful I mean attracting dozens of contributors or more). 
Looking at the lobse.rs discussion Guillaume posted, Hacker news 
discussion about OpenD and considering what you hear about say 
Linus Torvalds or Theo de Raadt, strong enthusiasm to contribute 
seems to go hand in hand with a strong personality. I think 
keeping those kinds of contributors is simply hard. It might not 
be that hard for an average Joe were he leading, but I suspect 
the same qualities that make language creators succesful in the 
first place tend to make good leadership in these cases hard for 
them.

I don't think D leadership is doing particulary badly - otherwise 
they would be developing the compiler alone by now. But sure it's 
still a critical thing that might well determine the future 
between stagnation and an explosion in popularity. Therefore 
you're right we ought to pay attention to it, however 
understandable the problems are.



 Jan 19



  parent reply Don Allen <donaldcallen gmail.com>  writes:


On Friday, 19 January 2024 at 09:50:06 UTC, Dukc wrote:

 On Thursday, 18 January 2024 at 20:51:48 UTC, Paul Backus wrote:

 Yes, that's certainly true.

 My intent is not to focus on Adam Ruppe's case specifically, 
 but on the broader pattern that also includes former 
 contributors like Sebastian Wilzbach, Jonathan Marler, 
 ag0aep6g, Suleyman Sahmi (SSoulaimane), etc. When one 
 relationship fails, that's unfortunate. When a long string of 
 relationships fail in the same way, that's a sign of a deeper 
 problem.

 Even if we grant that there was nothing more to be done in 
 Adam's case, I think D's approach to contributor relationships 
 is leaving a lot of value on the table.


 I get the impression that these kinds of problems are more of a 
 rule than an exception in succesful open-source projects though 
 (by succesful I mean attracting dozens of contributors or 
 more). Looking at the lobse.rs discussion Guillaume posted, 
 Hacker news discussion about OpenD and considering what you 
 hear about say Linus Torvalds or Theo de Raadt, strong 
 enthusiasm to contribute seems to go hand in hand with a strong 
 personality. I think keeping those kinds of contributors is 
 simply hard. It might not be that hard for an average Joe were 
 he leading, but I suspect the same qualities that make language 
 creators succesful in the first place tend to make good 
 leadership in these cases hard for them.

 I don't think D leadership is doing particulary badly - 
 otherwise they would be developing the compiler alone by now. 
 But sure it's still a critical thing that might well determine 
 the future between stagnation and an explosion in popularity. 
 Therefore you're right we ought to pay attention to it, however 
 understandable the problems are.


Again I agree with you.

Another obvious factor that makes open-source projects difficult 
to manage is that people are contributing voluntarily. Their 
livelihood doesn't depend on toeing the line, as it frequently 
does in paid employment. *And* they have access to the source 
code. So when personal styles clash, as I think was the case 
here, it's much easier for things like we've just seen with this 
project to happen.

I have personal experience with de Raadt (not good) and have used 
OpenBSD on and off for years. OpenBSD is absolutely a cult of 
personality, exactly as you said. But it takes a particular kind 
of personality to be willing to drink the de Raadt Kool-Aid. And 
recall that OpenBSD is a fork of NetBSD, the result of some 
particularly nasty circumstances.

So I think the right way forward is to learn what can be learned 
from this kerfuffle, but don't over-react to it. You certainly 
want to try to retain someone like Adam,  talented and volatile, 
but sometimes it's just not possible. C'est la vie.



 Jan 19



  parent reply Don Allen <donaldcallen gmail.com>  writes:


On Friday, 19 January 2024 at 15:01:21 UTC, Don Allen wrote:

 On Friday, 19 January 2024 at 09:50:06 UTC, Dukc wrote:

 On Thursday, 18 January 2024 at 20:51:48 UTC, Paul Backus 
 wrote:

 Yes, that's certainly true.

 My intent is not to focus on Adam Ruppe's case specifically, 
 but on the broader pattern that also includes former 
 contributors like Sebastian Wilzbach, Jonathan Marler, 
 ag0aep6g, Suleyman Sahmi (SSoulaimane), etc. When one 
 relationship fails, that's unfortunate. When a long string of 
 relationships fail in the same way, that's a sign of a deeper 
 problem.

 Even if we grant that there was nothing more to be done in 
 Adam's case, I think D's approach to contributor 
 relationships is leaving a lot of value on the table.


 I get the impression that these kinds of problems are more of 
 a rule than an exception in succesful open-source projects 
 though (by succesful I mean attracting dozens of contributors 
 or more). Looking at the lobse.rs discussion Guillaume posted, 
 Hacker news discussion about OpenD and considering what you 
 hear about say Linus Torvalds or Theo de Raadt, strong 
 enthusiasm to contribute seems to go hand in hand with a 
 strong personality. I think keeping those kinds of 
 contributors is simply hard. It might not be that hard for an 
 average Joe were he leading, but I suspect the same qualities 
 that make language creators succesful in the first place tend 
 to make good leadership in these cases hard for them.

 I don't think D leadership is doing particulary badly - 
 otherwise they would be developing the compiler alone by now. 
 But sure it's still a critical thing that might well determine 
 the future between stagnation and an explosion in popularity. 
 Therefore you're right we ought to pay attention to it, 
 however understandable the problems are.


 Again I agree with you.

 Another obvious factor that makes open-source projects 
 difficult to manage is that people are contributing 
 voluntarily. Their livelihood doesn't depend on toeing the 
 line, as it frequently does in paid employment. *And* they have 
 access to the source code. So when personal styles clash, as I 
 think was the case here, it's much easier for things like we've 
 just seen with this project to happen.

 I have personal experience with de Raadt (not good) and have 
 used OpenBSD on and off for years. OpenBSD is absolutely a cult 
 of personality, exactly as you said. But it takes a particular 
 kind of personality to be willing to drink the de Raadt 
 Kool-Aid. And recall that OpenBSD is a fork of NetBSD, the 
 result of some particularly nasty circumstances.

 So I think the right way forward is to learn what can be 
 learned from this kerfuffle, but don't over-react to it. You 
 certainly want to try to retain someone like Adam,  talented 
 and volatile, but sometimes it's just not possible. C'est la 
 vie.


I should add that I no longer use OpenBSD and will not, because 
de Raadt, brilliant though he is, is a nasty piece of work and 
his followers have, in many cases, taken on some of his 
personality characteristics. This is an example of organizations 
tending to behave like their leaders. I refuse to subject myself 
to that kind of aberrant behavior. The software is good but not 
good enough to put up with that.

Walter sets a very different tone for this project and I value 
that. The man behaves like a gentleman. Of course he's imperfect, 
just like the rest of us. But he tries to improve upon the 
imperfections. de Raadt? His way or the highway and that will 
never change.



 Jan 19



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 1/19/2024 7:46 AM, Don Allen wrote:

 Walter sets a very different tone for this project and I value that. The man 
 behaves like a gentleman. Of course he's imperfect, just like the rest of us. 
 But he tries to improve upon the imperfections. de Raadt? His way or the
highway 
 and that will never change.


I do agree that the tone of any organization flows down from the top, so it's
up 
to me to lead by example.

The other thing I've tried to do, perhaps with more success, is to emulate the 
honor system used at Caltech when I attended it. I enjoyed it and appreciated
it 
very much as a student. It's unique to Caltech (other universities have honor 
systems, but with "adjustments"), and it's what made Caltech into a top shelf 
institution.

In the years that followed, Caltech added more conditions and complexities to 
it, to its detriment. The original (from memory) was simple and straightforward:

"No member shall take unfair advantage of any other member."

It had far reaching consequences. For example, exams were unproctored, 
take-home, with time limits. Nobody would know if you cheated or not. It was 
entirely up to one's honor.

Of course, there were cases of cheating. But it was never organized cheating. 
The students liked the honor system, and would ostracize anyone who took 
advantage of it. This was why organized cheating never happened. Cheating was a 
shameful thing one did in a closet, not something one bragged about getting
away 
with. Nor was theft an issue, people would leave their dorm rooms unlocked. The 
only thefts I heard of were from outsiders who wandered into the dorm.

The other interesting result of that is the professors and students became 
collaborators rather than adversaries.

I've never made any explicit mention of this with the DLF, but it's the way we 
operate. To my great satisfaction, the DLF members adhere to it. It's really 
marvelous.

For example, at our DLF conferences, nobody worries about leaving their 
possessions laying around.

But we did have an incident at the last DLF where a couple laptops were stolen. 
Unsurprising to me, the culprit turned out to be a person who wandered in off 
the street, not one of our attendees. Our response for the next DConf is to
hire 
a security person to gate keep at the door.



 Jan 19



  parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz>  writes:


On 20/01/2024 6:48 AM, Walter Bright wrote:

 I do agree that the tone of any organization flows down from the top, so 
 it's up to me to lead by example.


I mentioned about this to Atila in another post.

But I am hoping that he will continue to drop in on Discord to check for 
pings on a regular basis moving forward.

Ideally you too.

Why? Your email has been down for a while and I'm currently waiting on 
you to reply to a ping on GH.

Having leaders where the people are shows that you care, and want to be 
needed in that way.

As Mike said, the us vs them mentality has to go, and this could help to 
do it.

There are other things but I'll let Adam Wilson talk about it.



 Jan 19



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


I get a constant stream of requests for attention. There's only so much I can 
respond to. Adding another source will likely just make me less productive.



 Jan 19



 next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz>  writes:


On 20/01/2024 7:52 AM, Walter Bright wrote:

 I get a constant stream of requests for attention. There's only so much 
 I can respond to. Adding another source will likely just make me less 
 productive.


I can certainly understand that.

But all of these giant drama threads are already doing that, not to 
mention the loss of productivity of others.

That's the problem with leadership, you have to delegate, you can't do 
everything yourself.



 Jan 19



 next sibling parent reply Hors <q q.com>  writes:


On Friday, 19 January 2024 at 18:56:52 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 On 20/01/2024 7:52 AM, Walter Bright wrote:

 I get a constant stream of requests for attention. There's 
 only so much I can respond to. Adding another source will 
 likely just make me less productive.


 I can certainly understand that.

 But all of these giant drama threads are already doing that, 
 not to mention the loss of productivity of others.

 That's the problem with leadership, you have to delegate, you 
 can't do everything yourself.


i thought this was the definition of open source software, you 
can do things without needing a leader. Can't community discuss 
about things without leader, if leader declines it (which is 
unlikely if most of the people actually want it), then you can 
always fork.



 Jan 19



 next sibling parent  "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz>  writes:


On 20/01/2024 8:39 AM, Hors wrote:

 On Friday, 19 January 2024 at 18:56:52 UTC, Richard (Rikki) Andrew 
 Cattermole wrote:

 On 20/01/2024 7:52 AM, Walter Bright wrote:

 I get a constant stream of requests for attention. There's only so 
 much I can respond to. Adding another source will likely just make me 
 less productive.


 I can certainly understand that.

 But all of these giant drama threads are already doing that, not to 
 mention the loss of productivity of others.

 That's the problem with leadership, you have to delegate, you can't do 
 everything yourself.


 
 i thought this was the definition of open source software, you can do 
 things without needing a leader. Can't community discuss about things 
 without leader, if leader declines it (which is unlikely if most of the 
 people actually want it), then you can always fork.


Yes, but you have missed the very important point. He hasn't got the 
time to see something to decline it.

It is the old worker vs leader conflict. People don't have the time to 
perform both roles at full capability. Trying to keep both at full 
result in doing neither well. Not a good thing.



 Jan 19



prev sibling  parent reply "H. S. Teoh" <hsteoh qfbox.info>  writes:


On Fri, Jan 20, 2024 at 07:39:07PM +0000, Hors via Digitalmars-d wrote:
[...]

 i thought this was the definition of open source software, you can do
 things without needing a leader. Can't community discuss about things
 without leader, if leader declines it (which is unlikely if most of
 the people actually want it), then you can always fork.


Don't confuse the *license* of the software (license gives you the right
to access and modify the source code) with the *development methodology*
of the software (community decides what features to implement vs. leader
makes final decision vs. anything in-between).

D has always been closer to the closed development model where Walter
has final say over what goes in and what doesn't. Not quite as closed as
Lua (devs don't even grant access to the code repo, you only get the
code snapshot at release time, they may or may not listen to community
feedback and are not obligated to explain why), but still pretty near
the closed end of the spectrum than your average open source project
where the community's voice plays a bigger role.

However, in spite of what the open source / open development model
propagandists may say, it remains an open question which end of the
spectrum (or whether the exact middle) is more effective.  Having a BDFL
can help move things along when the community is split over some
controversial decision, and he can also ensure the big picture is not
lost in the forest of immediate decisions. OTOH having everything go
through one person has serious bottleneck issues and adversity issues
(when the community at large disagrees with the leader's decision).
There are pros and cons whichever way you take.  I have my opinion on
where on the spectrum things are more ideal, but it's not possible to
know for sure without actually doing it.  It's not an easy issue.


T

-- 
Notwithstanding the eloquent discontent that you have just respectfully
expressed at length against my verbal capabilities, I am afraid that I must
unfortunately bring it to your attention that I am, in fact, NOT verbose.



 Jan 19



  parent  Steven Schveighoffer <schveiguy gmail.com>  writes:


On Friday, 19 January 2024 at 20:22:07 UTC, H. S. Teoh wrote:

 D has always been closer to the closed development model where 
 Walter has final say over what goes in and what doesn't. Not 
 quite as closed as Lua (devs don't even grant access to the 
 code repo, you only get the code snapshot at release time, they 
 may or may not listen to community feedback and are not 
 obligated to explain why), but still pretty near the closed end 
 of the spectrum than your average open source project where the 
 community's voice plays a bigger role.


This is a bit far. Development of the compiler and the libraries 
are very open. In as far as Phobos (and to a great extent 
druntime) is concerned, Walter is not even involved. 3rd party 
projects that are essential to D's ecosystem are not actually 
even owned by DLF, but are still considered critical 
infrastructure.

Adding *features to the language* is a different story. It is 
very easy to "just add this new thing" without thinking about the 
far-reaching consequences. That will lead to a disaster IMO. I'm 
actually glad that DIP1036 (not the most latest thing, which was 
a modified version) did not just make it in on the first round, 
and we worked through the debates and came to 1036e. I've had 
other features that I invented that got added which are less than 
ideal and hard to correct (inout for instance).

I think D has done pretty well with Walter at the helm, and I'm 
not convinced the alternative would have been better. I don't 
want to make excuses, because I know what it's like to be on the 
receiving end of dismissal (it's one of the reasons I really 
don't try to make any sweeping changes to Phobos any more), but I 
think the current leadership situation is fixable, and we are 
better off trying to fix it than seceding.


 There are pros and cons whichever way you take.  I have my 
 opinion on where on the spectrum things are more ideal, but 
 it's not possible to know for sure without actually doing it.  
 It's not an easy issue.


I would expect most open source to be designed and modified with 
one person or a small team at the top dictating what is OK and 
what is not, with many others who are trusted contributors. D is 
not any different.

-Steve



 Jan 19



prev sibling  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 1/19/2024 10:56 AM, Richard (Rikki) Andrew Cattermole wrote:

 That's the problem with leadership, you have to delegate, you can't do 
 everything yourself.


Then I delegate anyone who uses Discord and thinks an issue there needs to be 
raised in the n.g., to please do so.

And, as always, bug reports go on bugzilla. It's only fair to give priority to 
bug reports where the bug reporter made an effort to post them there.

Bug reports of the form "the latest release broke my code!" with no further 
elucidation are completely and utterly useless. There is nothing I nor anyone 
else can do about them.



 Jan 19



prev sibling  parent  Dibyendu Majumdar <d.majumdar gmail.com>  writes:


On Friday, 19 January 2024 at 18:52:15 UTC, Walter Bright wrote:

 I get a constant stream of requests for attention. There's only 
 so much I can respond to. Adding another source will likely 
 just make me less productive.


In Linux world, the leads just review and merge. It is difficult 
to both be the main compiler developer and also the project lead 
who must review PRs.



 Jan 19



prev sibling  parent  Dibyendu Majumdar <d.majumdar gmail.com>  writes:


On Monday, 15 January 2024 at 10:11:33 UTC, IGotD- wrote:


 Is there no bottom how low you can go?


Its funny this, as you are the one we should ask this question.

Since you don't like it here, why are you here?

I don't use D so I am just a bystander, but here is a thought.
Try behaving this way over at OpenD and see how open people are.



 Jan 16



prev sibling next sibling parent  Lance Bachmeier <no spam.net>  writes:


On Monday, 15 January 2024 at 09:46:11 UTC, Atila Neves wrote:


 We hope that in time the contributors to OpenD will decide to 
 lend
 their time instead to the D language.


One might argue that's what they're doing. D doesn't have the 
tools in place for the language to evolve or for most people to 
productively contribute. Rather than arguing for months about 
things that in the end never get done, code can be added to OpenD 
and we can see what does and doesn't work.



 Jan 15



prev sibling next sibling parent  claptrap <clap trap.com>  writes:


On Monday, 15 January 2024 at 09:46:11 UTC, Atila Neves wrote:

 As seen on this very same forum / mailing list, some of the 
 members of
 the community have decided to fork D over disagreements with how
 things are being run.


I was very disappointed to read the whole post and find that the 
promised elephant was nowhere to be found. The idiom generally 
means "something huge and obvious that everyone is tiptoeing 
around as if it doesn't exist ". On contrary it's all been talked 
about top to bottom, endlessly.

I had hope for some juicy diversion from the endless talk of 
string interpolation, sliding whatnots and forks up the 
proverbial... But alas I will have find that elsewhere.

Top marks for click-baity title though!



 Jan 15



prev sibling next sibling parent  jmh530 <john.michael.hall gmail.com>  writes:


On Monday, 15 January 2024 at 09:46:11 UTC, Atila Neves wrote:

 As seen on this very same forum / mailing list, some of the 
 members of
 the community have decided to fork D over disagreements with how
 things are being run.


People still make references to Tango vs Phobos, which happened 
years before I even heard of D. I suspect people will be using 
this current disagreement as an excuse to touch neither for some 
time. Rightly or wrongly.



 Jan 16



prev sibling  parent  une <une abcde.fg>  writes:


On Monday, 15 January 2024 at 09:46:11 UTC, Atila Neves wrote:

 We hope that in time the contributors to OpenD will decide to 
 lend
 their time instead to the D language.


maybe dlang should embrace closedness [1] and actually encourage 
language forks

benefit
- it will save everyone's time. dlang org spends energy making a 
great language for their customers, dlang staff don't spend time 
on N.G.
- zero expectation. language contributors will know upfront they 
should spend time on their own thing.

con
- community fragmentation - not an issue, those who quit are lost 
forever anyways.

[1]
https://lua.org/faq.html#1.8
https://lua.org/faq.html#1.9
http://lua-users.org/lists/lua-l/2008-06/msg00407.html



 Jan 19