Breaking D2 language/spec changes with D1 being discontinued in a month

[John Colvin]

On Wednesday, 28 November 2012 at 13:15:26 UTC, Jacob Carlborg 
wrote:
> On 2012-11-28 13:41, Walter Bright wrote:
>
>> On the other hand, many people were unhappy with my position 
>> of "no
>> breaking changes at all outside of clear bug fixes" to D1, 
>> which also
>> implied "no language enhancements". There were many 
>> enhancements to the
>> code generation, new platforms, etc., and many CTFE 
>> improvements (which
>> I more or less regarded as bug fixing). There were also no 
>> changes
>> allowed that affected binary compatibility.
>
> Please, please try and understand. It's not breaking changes in 
> it self that is the problem. It's how they're handled.
>
> Many people has also talked about something in between D1 and 
> D2, D1.5 or similar. Which would contain bug fixes and new 
> backwards compilable changes.

For what it's worth, I agree.

I think that the current "core" developers of D are exceptional 
programmers, with a very astute eye as to what makes a good 
programming language and the skills to implement it.

That said, the management of D is relatively poor.

For any programming language to make headway in the real world 
(i.e. not in the language aficionado's playground) it HAS to have 
some form of stable branch *. The documentation MUST be up to 
date and complete for that stable branch, including all the 
things that are wrong with it!

A path I see

1. Redirect current efforts towards stability **, aiming to 
produce a major release of DMD+druntime+phobos with complete and 
__honest__ documentation (i.e. admitting that something doesn't 
quite work right, "use at your own risk"). Then, make an 
aggressive push to get that stable release into use in 
mainstream, large-scale projects, which given D's power, combined 
with stability, should be much easier than before.

2. Someone takes on a significant managerial/admin position, who 
has responsibility over the documentation and stable releases of 
D. This would be a pretty unexciting job, so it probably needs to 
be paid in order to get it done well. After part 1, finding some 
money shouldn't be so hard.


My fear is that if the D rocket doesn't lift off now, it never 
really will.


* Look at python for example. Effectively the entire language is 
branched every so often and stabilised, including the standard 
library. Major release numbers signify a particular "branch", 
which is then pushed towards it's most stable state, while new 
features and significant code-breaking changes go in the next 
version number.

** Please note that I do NOT mean making the language work 
perfectly, fixing every bug. I mean fixing a lot of the low 
hanging fruit and properly documenting the problems that remain.