new domain: d-programming-language.org

Jari-Matti Mäkelä jmjmak at utu.fi.invalid
Tue May 9 12:59:41 PDT 2006


Walter Bright wrote:
> 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.

Ok, I agree. I just read from your previous post that the development of
D is now officially concentrated on bug fixing and making a stable
release with working add-on software. It all makes a lot more sense now.

> 
>> 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.

Yes, I agree on this one too. Again I thought that there's no serious
feature-freeze going on. I was just worried that it's getting too hard
to keep up with the upcoming proposals. I know it has been discussed
before, but some kind of roadmap indicating that the current beta-state
is soon over would look good on digitalmars website.

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

Luckily D is a practical language. :)

-- 
Jari-Matti



More information about the Digitalmars-d-announce mailing list