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?).
