Do we need a time-out in D evolution?

Falk-Florian Henrich schreibmalwieder at hammerfort.de
Wed Jun 6 05:13:42 PDT 2007


Am Tue, 05 Jun 2007 20:25:03 +0400 schrieb eao197:

> I'm watching for discussions 'Stepping back and looking at constness
> from another angle' here and 'resizeable arrays: T[new]' & 'preparing
> for const, final, and invariant' in digitalmars.D.announce and I'm sad.
> I occasionally locked to D may be from 2003 -- it was a constantly
> changing language. At the end of 2006 I thought that D is stable enough
> to start to use it. And in Jan 2007 the v.1.000 went out. I thought that
> in near time D would have only bug fix releases and it is a time when
> various tools for D (like libraries and IDEs) would be produced.
> 
> But I was wrong.
> 
> What we have now? The language which keeps their evolution. Lack of
> libraries, lack of tools, lack of documentation (books and tutorials).
> As a consequence -- lack of users. And we don't get much new users and
> new applications without new libraries/tools/documentation.
> 
> As a programmer I need a stable language. A language in which I can
> write a domain-specific library and forget about its maintenace for
> three of five years (as for some of my C++ libraries those I wrote in
> 2002-2003). I need to write applications and because of that I need a
> quality and stable compiler, a quality and stable standard library, and
> quality third party libraries. And third party libraries' writters need
> a stable tools too.
> 
> But now, when I'm writting some D code, I know that in near feature the
> next D version will be here. And that version broke my code because of
> consts and new syntax of resizeable arrays. So why to start a new big
> project on D if its codebase will be obsolete in few months?
> 
> And I'm affraid that after adding consts/final/invariant support to D
> the language keeps their envolution :(
> 
> Yes consts/final/invariant is a great addition to the language. But D
> now is very powerful language. It is now more powerful than C++0x will
> be. So may be it is better to stop add new features and make a stable
> platform for library/tools writters at first and then for applications
> writters? AFAIK, every successful languages were going such way -- the
> good initial release and some new releases later with years of stability
> beetwen them. And I'm affraid that C++0x will be here before D would get
> a stable language with enough libraries and tools.
> 
> May be it is better to concentrate on improvement of the current
> implementation (fast precise GC instead of the current conservative GC,
> for example) instead of introducing incompatible changes in the
> language?
> 
> And my main question is: will be D a constanly changing language or will
> be there some time-outs in its evolution?
>

I totally agree. The priority given to the "hunt for features" will take 
us nowhere. Instead of designing and implementing a couple of new 
features every other month it would be more appropriate to first fix at 
least the major bugs in the compiler.

D already as an amazing set of features which surely can be used to 
produce awesome code.

On the other hand, the compiler is buggy and does not comply with the 
language specification. Let me give a concrete example [1]:

The D spec allows for parametric polymorphism via template functions. 
This sounds great, but the compiler's broken type inference algorithm 
renders it useless: If I have a function template F that takes some 
ordinary function f as a parameter [2] the spec allows me to use 
overloaded variants of f as instantiation parameter to F. Unfortunately, 
the type inference (in template.c) is simply a mess of intertwined gotos 
and other unreadable stuff [3]. Worse, it cannot cope with the situation 
[4]: Instead of choosing the appropriate overload of f, it just takes the 
first variant it finds in the source file. This renders parametric 
polymorphism unusable in practice.

Maybe, all this sounds a bit harsh, but it's simply the truth. My purpose 
of stating these problems is surely not to insult anyone, but to show 
that completing the implementation of the existing concepts is much more 
worthwhile (as of 2007) than crafting some "killer feature". Otherwise, I 
fear D's user base will not grow any further.

Falk


[1] Many people (including myself) have mentioned this bug before. I 
repeat the story here, because I think it shows how the usefulness of a 
feature vanishes completely if its implementation was done in a haste.

[2] Via this technique a lot of keyword bloat (foreach etc) could be 
avoided -- if the compiler would obey the spec.

[3] I tried to debug it but didn't succeed, since I'm not a compiler 
expert and the documentation is not very helpful.

[4] There are many, many other problems with D's type inference. This 
finally led me to the conclusion that its implementation is a dirty hack 
-- which I don't know the reason for, since there exist working type 
inference algorithms at least since the seventies.



More information about the Digitalmars-d mailing list