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.

Reply via email to