On Tuesday, 22 September 2015 at 15:34:19 UTC, Chris wrote:
> Then we need a transition strategy. I wouldn't mind refactoring my code in order to adapt it to changes that are for the better in the long run. However, I wouldn't want it to happen in a sudden way that would render all my code useless. Nobody would accept this.

I agree, one could have an experimental compiler that accepts a modified subset of current D, yet is capable of linking with existing D code perhaps.

On Tuesday, 22 September 2015 at 13:38:33 UTC, Chris wrote:
> it's only from D that users expect perfection, other languages are accepted as they are, warts and all.
it's true

On Tuesday, 22 September 2015 at 11:01:28 UTC, Chris wrote:
> The thing is that a lot of people who use D don't mind the lack of IDE support. One reason is that D doesn't need it as badly as e.g. Java or C++.

These are bad excuses.

On Tuesday, 22 September 2015 at 13:38:33 UTC, Chris wrote:
> On Tuesday, 22 September 2015 at 11:44:35 UTC, Maxim Fomin wrote:
>> On Tuesday, 22 September 2015 at 11:01:28 UTC, Chris wrote:
>>>
>>> to be confined by committee decisions etc.,
>>
>> D has committee (Walter & Andrei). Some of their decisions frustrate D users too.
>
> 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.

> That these decisions are not always to everyone's liking is inevitable. Given the contradictory nature of requirements in programming, it's only logical that one cannot cater for both sides all the time.

Definitely agree.

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

On Tuesday, 22 September 2015 at 18:17:42 UTC, Maxim Fomin wrote:
> Two examples. I am aware of only one case when Walter and Andrei agreed with community.

Well, but the community doesn't agree with itself either ;^) But Walter did add @nogc and changed his view on GC being a total non-issue, so obviously forum discussions have an effect on the decision-making process over time.

> So, my point is that D except communication channel is pretty much the same as standardized languages with respect to changing language.

I think the process changes a lot when you are working with an actual language spec for several years and get experimental implementations in compilers a long time before release. Add also the number of qualified eyeballs looking at proposals... I don't think the C++ designers have made many serious mistakes in the last few iterations (although it could happen again in C++17 ;^).

When the spec is the compiler, then you get the unfortunate effect that things that are easy to do go in, and things that are hard to do are rejected.

Anyway, some of these things are discussed in Stroustrup's keynote:

https://github.com/isocpp/CppCoreGuidelines/blob/master/talks/Stroustrup%20-%20CppCon%202015%20keynote.pdf

On Tuesday, 22 September 2015 at 18:30:35 UTC, Ola Fosheim Grøstad wrote:
> I think the process changes a lot when you are working with an actual language spec for several years and get experimental implementations in compilers a long time before release. Add also the number of qualified eyeballs looking at proposals... I don't think the C++ designers have made many serious mistakes in the last few iterations (although it could happen again in C++17 ;^).

Though there was a questionable change in C standard: introduction of timespec, which locally redefined meaning of time_t as a transparent type, along with legacy definition of time_t as an opaque type. Maybe legacy definition could be dropped, but it didn't happen.

On Tuesday, 22 September 2015 at 18:17:42 UTC, Maxim Fomin wrote:

>>
>> Well, in case of C/C++ there is also rationale for decision, but not in the forum form.

Yes, but you get it post facto and nobody listens to you anyway, it's like a parliament.

>> But providing rationale is not helpful if there is disagreement.

Well, what do you suggest then? To implement a different fork of D for every opinion / user request? Excuse me, but I cannot follow your rationale. It is only when there is disagreement that you have to provide a rationale. If there is general agreement you don't need to provide a rationale.

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

Yes, but where do you draw the line between random requests (sometimes contradictory) and real long-term enhancements? As Ola said, the community often doesn't agree with itself.

> Secondly, it is hard to beat the 'committee' argumentation even if they are wrong - they are simply to skilled and experienced.

Yes, it's hard to beat experience. However, if a feature - albeit useful - would break too much code, Walter takes a conservative stance, else D would lose most of its clients. We need a proper transition strategy.

[1] https://github.com/higgsjs/Higgs

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

There has been a lot of movement. E.g. when Higgs[1] couldn't beat C++'s performance, Walter and Andrei agreed (as far as I remember) that the current GC is indeed an issue as is full C++ compatibility. And there are other cases. I think the problem is that everybody has their own pet issues and follows only these - and if there is no movement, they get the impression that nothing ever happens (you know, toys, pram...). However, if you follow this forum over the years, you can see that there is movement due to user input.

The question is, do certain issues really keep you from using the language successfully and why? And is it an issue for a substantial part of other users?

On Tuesday, 22 September 2015 at 17:42:27 UTC, deadalnix wrote:
> On Tuesday, 22 September 2015 at 11:01:28 UTC, Chris wrote:
>> The thing is that a lot of people who use D don't mind the lack of IDE support. One reason is that D doesn't need it as badly as e.g. Java or C++.
>
> These are bad excuses.

Not an excuse, an explanation. Two different things.

Since the D community is not big nor backed by a huge corporation, people who want something have to work on it themselves. There simply is no other way.

On Wednesday, 23 September 2015 at 09:44:10 UTC, Chris wrote:
> Yes, it's hard to beat experience. However, if a feature - albeit useful - would break too much code, Walter takes a conservative stance, else D would lose most of its clients. We need a proper transition strategy.

C++ seems to take a guideline + guideline support library (GSL) in order to "softly deprecate" the old feature set without actually deprecating it. I am not sure how well that goes, but GSL looks good to me.

When a language reach a certain complexity it probably is a mistake to add more features, new features have to be followed by instruction of how to make good use of them. In C++ there are too many ways to do the same thing, which is negative for code legibility.

His talk is online:

https://youtu.be/1OEu9C51K2A

> The question is, do certain issues really keep you from using the language successfully and why? And is it an issue for a substantial part of other users?

Another question is: what kind of competing solutions are emerging. Herb Sutter seems to have focused his cppcon talk on Rust style memory management in C++. The adoption of Rust does force the C++ designers to switch gears and hopefully the competition will create a push for better solutions.

That applies to D too, I think.

Rust also aims for commercial level stability for Rust 1.4. (I don't think they will be able to, but let's see.) This is also a threat for C++.