Vision for the D language - stabilizing complexity?

[Andrew Godfrey via Digitalmars-d]

On Monday, 18 July 2016 at 09:45:39 UTC, Chris wrote:
> On Sunday, 17 July 2016 at 02:17:52 UTC, Andrew Godfrey wrote:
>> On Saturday, 16 July 2016 at 21:35:41 UTC, Walter Bright wrote:
>>> On 7/16/2016 6:09 AM, Andrew Godfrey wrote:
>>>> Walter called Prolog "singularly useless". You have been 
>>>> referring to changes
>>>> that would amount to a new major version of D as "a 
>>>> cleanup". From the forums,
>>>> my sense is that there IS a groundswell of opinion, that D2 
>>>> has some major
>>>> mistakes in it that can't be rectified without doing a D3, 
>>>> and there's a strong
>>>> reaction to that idea based on experience with D1 -> D2. 
>>>> Perhaps what is needed
>>>> is a separate area for discussion about ideas that would 
>>>> require a major version
>>>> change. The thing about that is that it can't be done 
>>>> incrementally; it's the
>>>> rare kind of thing that would need to be planned long in 
>>>> advance, and would have
>>>> to amount to a huge improvement to justify even considering 
>>>> it.
>>>
>>> I agree that D2 has made some fundamental mistakes. But it 
>>> also got a great deal right.
>>>
>>> I haven't banned Ola from the forums, he has done nothing to 
>>> deserve that. He's welcome to post here, and others are 
>>> welcome to engage him.
>>
>> I'm more interested in engaging on "in how many years will the 
>> D leadership be interested in engaging on the topic of D3?" I 
>> feel this is a significant omission from the vision doc, and 
>> that omission inflames a lot of the recurring animosity I see 
>> on the forums. Even an answer of "never" would be a 
>> significant improvement over "we refuse to engage on that". 
>> And I doubt you're really thinking "never".
>>
>> I do think that ideas from academia will mostly cause a lot of 
>> unwanted noise in such a discussion - because academia, in my 
>> experience, is more focused on "software construction" than on 
>> "software evolution", and D takes an approach that is built on 
>> practical experience with evolution. But academia also has 
>> occasional nuggets of extreme value.
>
> The question is what is D3 supposed to be? I'm neither for nor 
> against D3, it pops up every once in a while when people are 
> not happy with a feature. My questions are:
>
> 1. Is there any clear vision of what D3 should look like?
>
> 2. What exactly will it fix?
>
> 3. Is there a prototype (in progress) to actually prove it will 
> fix those things?
>
> 4. If there is (real) proof[1], would it justify a break with 
> D2 and risk D's death?
>
> I think this topic is too serious to be just throwing in 
> (partly academic) ideas that might or might not work in the 
> real world. It's too serious to use D as a playground and later 
> say "Ah well, it didn't work. [shrug]". D has left the 
> playground and can no longer afford to just play around with 
> ideas randomly. One has to be realistic.
>
> I'd also like to add that if we had a "clean and compact" D3, 
> it would become more complex over time and people would want D4 
> to solve this, then D5 and so forth. I haven't seen any 
> software yet that hasn't become more complex over time.
>
> Last but not least, it would help to make a list of the things 
> D2 got right to put the whole D3 issue into proportion.
>
> [1] I.e. let's not refer to other languages in an eclectic 
> manner. I'm asking for a proof that D works as D3 and is 
> superior to D2.

We risk scaring away potential community members, and alienating 
existing ones, by the way we say "no" to proposals for breaking 
changes. We could improve how we say "no", by having a place to 
point people to. Potential topics:

1) As you say, a vision for D3. Maybe just a summary of the 
things that are now agreed upon, e.g. autodecoding (though even 
there, I think the details of where to move to, are still 
contentious. E.g. I personally dislike the convention of "char" 
meaning a 1-byte data type but I think some others like it).

2) The case against incremental breaking changes. (I see this 
argument somewhat, though it applies less to "dfixable" breaking 
changes).

3) Why we feel that breaking changes risk killing D outright. (I 
just don't see it. I wonder if we're confusing "dfixable" 
breaking changes, with other more disruptive kinds (such as 
Tango=>Phobos).)