standardization of D

[Sean Kelly]

Ameer Armaly wrote:
> Hi all. There are a few things which have been bothering me as of late, and 
> I want your opinions on them to know whether or not I'm jumping at shadows. 
> For starters, we all have a common goal of making D as widely used as 
> possible since we all love the language, otherwise we probably wouldn't be 
> here. At the same time, there are a few factors which as I see it make the 
> adoption of D much more difficult and need to be addressed if we intend to 
> succeed:
> 1. 1.0 doesn't appear to be any special sort of marker with regard to the 
> standard; we have not only CTFE but mixins added post-1.0, along with 
> numerous changes to the _standard_library. I understand the compiler can be 
> made to strictly conform to the 1.0 spec, but the fact still remains it 
> seems very ad hoc. What ought to happen IMO is that we first call a review 
> of the language spec where everyone sends in any complaints they have and 
> they must be clearly addressed to everyone's satisfaction, or at least to 
> the degree that's possible. Then, the spec ought to be frozen for a while, 
> and we work strictly on the standard library, which I'll address later. 
> Then, the whole D language, including standard library, ought to be frozen 
> for several years to let it proliferate throughout the technical community; 
> an experimental compiler can of course undergo development, but clearly 
> marked as such and _separate_ from the stable compiler.

The idea of a separate compiler for experimental features has come up in 
the past and I think it's a good one.  But if it's easier for Walter to 
maintain a single compiler and provide a feature switch then that seems 
fine as well.  Also, other review models have been suggested, with the 
Python approach suggested as one alternative IIRC.  This is ultimately 
up to Walter however, and the method he feels would be most productive 
or beneficial to language development.  I can't claim to have any strong 
feelings here one way or the other.

> 2. We have two competing standard libraries; this is nowhere near good. 
> Phobos is basically built on C wherever possible and sort of thrown 
> together, and Tango reminds me of Java with a class for everything and then 
> some. For the standard's sake (and consequent adoption), D needs one 
> accepted standard library.

For what it's worth, Tango is only positioned as a "standard library" 
because it includes compiler runtime features (out of necessity), and 
because of its scope.  It was never intended to compete directly with 
Phobos.  To some, this distinction may be simply a matter of semantics, 
but I do feel it's important to point this out since it was never our 
intention to confuse things.  That said, if a choice truly had to be 
made between Phobos, Tango, etc, for a "D standard library" then that 
choice will be made by the community simply by virtue of whatever 
library each individual decides to use.  I don't know that an arbitrary 
decision would carry much weight here.

 > The current state makes that difficult because
> Walter is forced to hand-manage both the compiler and library.

I think there is some benefit to Walter maintaining Phobos, as it allows 
new compiler releases to include library code demonstrating or 
supporting the use of new language features.  This is something that 
would be more difficult to achieve if the library work were handled by 
someone else.  That isn't to say that there are no alternatives to this, 
but it bears mentioning.

 > What ought to
> happen IMO is that Walter should delegate day to day library management to a 
> trusted associate who will occasionally inform Walter of the latest 
> developments; Walter makes the final call, and life goes on.

There is also the issue of maintaining the compiler runtime code vs. the 
remainder of the library code.  Whatever happens at the user level, the 
compiler writer will want to maintain any runtime code that compiler 
requires.

> So to conclude, these are issues that have been sort of addressed at various 
> times in other issues, but never to a point that accomplished the intended 
> goal. The D community is growing; there are going to be a lot of new people 
> that look at it now and say "Huh? Say again?" Maybe we ought to step back 
> and forget the years we've had to become comfortable with D and analyze it 
> from a potential user's point of view in order to make adoption easier.
> Thoughts? 

Only that D is still a young language and that I feel things will sort 
themselves out in time.  Until then, we can simply do our best to 
clearly answer any questions posed by new users and to avoid overt 
conflict in public discussions.  After all, the way we interact with one 
another reflects upon D as a whole, and if we can't make sense of what's 
going on then how is a new user supposed to? :-)


Sean