new domain: d-programming-language.org

[Walter Bright]

Jari-Matti Mäkelä wrote:
> What I meant was that why doesn't Walter want to document approved
> future language features before implementing them. It would be a lot
> easier for other frontend writers to create patches / own
> implementations if there was some documentary in the first place. Walter
> could even tag them with something like "[not implemented yet, will be
> implemented in DMD 1.5 or 2.0]". The Future-link in digitalmars-site is
> badly outdated and inadequate. The bugzilla isn't good for describing
> the syntax or features in a verbose manner.

I don't like bugzilla for new feature requests because:

1) Some idiot will inevitably declare D as "buggy" because bugzilla 
contains nnnn bug reports, never mind that some large proportion of it 
is not bug reports, but feature requests. Perception is very, very 
important, and putting feature requests in bugzilla makes them look like 
bugs. I have long experience with the shallow QA technique of merely 
counting the number of entries in a bug database and attempting to infer 
"quality" based solely on that number. (This was also much of the basis 
of my reluctance to use bugzilla at all.)

2) Bugzilla is a terrible mechanism for discussion, debate, etc. 
Newsgroups do threaded discussions very well, but newsgroups are not 
good for long term discussion, and there tends to be lots of duplication 
and fluff. A wiki seems to be ideal for this purpose, however.

3) There's generally very little argument about something being a bug or 
not. But for a feature, there's always lots of room for discussion, 
alternate syntaxes, various pros and cons, etc. None of that fits in 
with the binary is/isnot nature of bugzilla.

> I know there are proposals in bugzilla and in the newsgroups. The
> problem is that these are not official in any way. We don't know, what
> would the final implementation be. I bet it would accelerate the
> development of D as a language if there were some centralized guidelines
> somewhere. It would also eliminate some missteps like builtin regexps or
> bit arrays if we could see them syntactically before they are in the
> "production" version. I don't know how Walter sees this, but IMHO
> writing few pages of text in a natural language is a lot less time
> consuming than writing them as a code to the compiler. And you have to
> write those damn docs anyway sooner or later.

Discussion of a new feature will only get you so far. To know if it is 
right or not, it has to be implemented, and then used in a real program. 
Take a look at C++, for example. The features in it where the committee 
standardized existing practice work, the features designed by the 
committee as the result of endless discussions and expert review (but no 
implementation), don't work.

The bit feature sure did look good on paper <g>.

It reminds me of when I had some discussions with a professional race 
car driver. He said that if you weren't once in a while walking back to 
the pits carrying just the steering wheel, you weren't trying hard 
enough. If you were walking back too often, you were not thinking.