Moving back to .NET

[Maxim Fomin via Digitalmars-d]

On Tuesday, 22 September 2015 at 17:43:59 UTC, Maxim Fomin wrote:
> On Tuesday, 22 September 2015 at 13:38:33 UTC, Chris wrote:
>>
>> Sure, but in many cases D allows you to work around decisions 
>> you don't like. Plus, you can actively contribute, make 
>> suggestions and prove your case. The length of some threads 
>> shows that Walter, Andrei and others involved in the 
>> development take input seriously and answer questions and give 
>> the reasons for their decisions.
>
> Well, in case of C/C++ there is also rationale for decision, 
> but not in the forum form. But providing rationale is not 
> helpful if there is disagreement.
>

To elaborate. If the issue is comparing chances of changing 
language in a user-oriented way of D and standardized languages, 
then it is definitely no. First of all, there is huge information 
gap between language hackers and users. Secondly, it is hard to 
beat the 'committee' argumentation even if they are wrong - they 
are simply to skilled and experienced.

Two examples. I am aware of only one case when Walter and Andrei 
agreed with community. It is epic bugzilla discussion [1] 
regarding contract programming. It took 60 comments to convince.

[1] https://issues.dlang.org/show_bug.cgi?id=6857

The second example is more recent dmd pull discussion regarding 
template linkage behavior (Walter + Martin vs. Kenji). After long 
discussion the outcome was that some rare but used feature was 
dropped for the sake of dmd internals convenience. Walter's 
argumentation was that the language feature was working by 
chance, so relying on it is a mistake (to be more precise, the 
question was whether to write new code to support feature in 
another context or to drop it and make code cleaner). After new 
release there were couple issues filed in bugzilla that 
complained about new behavior, but were closed as invalid (sorry, 
don't have link, recollect from memory).

So, my point is that D except communication channel is pretty 
much the same as standardized languages with respect to changing 
language. I would say there are better chances that some feature 
will suddenly be changed and backfire existing code rather than 
user will convince to tweak the existing features to make it user 
- friendly at the expense of internals complexity. I do admit 
that discussions of new features and simple enhancements provide 
better chances (discussion is about significant issues, not 
trivial enhancements - isn't it?).