The forked elephant in the room

[Mike Shah]

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!