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.