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?"

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.

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*?

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.

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.

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.

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.

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.

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!

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.