Reddit: why aren't people using D?

[Walter Bright]

Michiel Helvensteijn wrote:
> Here's the opinion of an 'outsider'. I've experimented a bit with D in the
> past (years ago), but have lately just followed the newsgroup out of
> general interest.
> 
> I respect the expertise and hard work of the D team, but I won't use D. And
> here's an incomplete list of my reasons. I imagine there are other
> programmers who share my views. Most of these issues, if not all, are well
> known here. But I'll mention them anyway.

Thanks for taking the time to let us know your thoughts.


> Please forgive (and correct) any factual mistakes. I'm sure there will be
> some. If you reply to any point in the list, I'll be glad to elaborate.

Ok.

> D offers too many ways to do the same thing:
> 
> * const, enum, immutable, invariant

invariant is deprecated and completely replaced by immutable. So now 
we're down to three <g>. The uses are:

immutable - data that cannot change or be changed (imagine it is stored 
in ROM)

const - read only view of data, you cannot change it but others can

enum - compile time constant, has no storage

The only place these overlap is in the declaration of symbolic 
constants. C++ has all three, but in a way that is context dependent 
that very few people are aware of.


> * structs, classes

structs are value types, classes are reference types. That's a 
fundamental distinction, not two ways to do the same thing. A lot of 
confusing problems with C++ code stem from attempting to use a struct 
(or class!) both ways, or trying to give it characteristics of both.


> * functions, delegates, lazy parameter evaluation

Lazy parameter evaluation may turn out to be a bad idea, it doesn't seem 
to have found its "groove" anywhere. On the other hand, you can just 
ignore them like everyone else does, like everyone ignores exception 
specifications in C++.

There's some undeniable extra complexity in having both function 
pointers and delegates. At some level, function pointers must be 
supported in order to support the C interface. Delegates are just too 
useful to give up (C++ has had awful problems trying to work around not 
having them - member function pointers anyone? Boost::bind? no thanks).

It is technically possible to wrap delegates with a thunk so they are 
interchangeable with function pointers, but this thunk has to be created 
at runtime. It'll have a corresponding performance and memory 
consumption penalty. It's hard to know if it's an acceptable cost or not.


> * garbage collection,

Many programming paradigms are not practical without gc.

> manual D memory management,

It's possible to do this, but rather pointless. It's only there for 
people who insist they need it.

> manual C memory management

Necessary to support the C ABI. But D actually does not have C memory 
management - to do C memory management, you call the C functions 
malloc/free. Those are not reimplemented in D.

D programs have complete access to C runtime libraries, and naturally 
this includes any C memory management functions.

> Even with so many ways to ensure const correctness, it is still possible to
> cast constness away, either making it impossible for the compiler to make
> any assumptions regarding constness, or making it very dangerous to do the
> cast.

Being a systems programming language, it must be possible to defeat the 
static type checking system for special cases. Yes, you can cast away 
constness, but (unlike in C++), if you use that power to change the 
value, you are in undefined territory. The compiler is allowed to assume 
that const-ness is respected.

In C++, it is legal and defined behavior to cast away const (unless it 
is a top level const) *and* change the value. This makes const 
completely useless as a hint to the code generator.

> D offers some cool features, but leaves them very underpowered:
> 
> * Contract programming (no contract inheritance, no compile-time static
> analysis, no loop invariants / ranking functions)

True, but compile-time static analysis is a "quality of implementation" 
issue. Furthermore, I know of no language other than Eiffel that has all 
this, and nobody uses Eiffel.


> * Class/Struct properties (no control over their use by class designer, no
> way to use +=, -=, no global properties, no parameterized properties)

I don't understand what this means.

> * Operator overloading (no fine control over comparison operators,
 > fixed commutativity,

This is deliberate. Operator overloading should be restricted to 
implementing arithmetic like operations on objects, not completely 
different things like what iostreams, Spirit and Boost::regex do.

> confusing rule priority to determine translation,

The alternative is "Koenig lookup", which I guarantee is far more 
confusing and has many weird problems.

> no overloading of !, &&, ||,

That's deliberate. For !, I wish to maintain the property of negation of 
the boolean result, as much of the semantics of transformation depend on 
it. For && and ||, they are "short circuit" operators, and how that 
would sensibly interact with operator overloading I have no idea.

I know of no language that allows overloading && and ||.

>  <>=)

I need to fix that.


> * Tuples (no dedicated syntax, no parallel assignment, no non-flattening
> tuples without workarounds, no returning tuples)

The flattening thing is a problem. The rest can be done with better 
library support.

> * Unit testing (not at compile time,

You can do testing at compile time with static asserts.

 > not possible to categorize)

I agree that D's built-in unit testing is basic. But the fact that it 
exists *at all* is a huge improvement for a programming language. I 
firmly believe that its mere existence has been a big factor in 
improving the general quality of D code.

The fact that you want more from unit testing is great. Unit testing has 
raised the bar of expectations on a language, and in that it's a home run.

> There are two competing standard libraries for D. This has been discussed to
> death and I won't go further into it. But it's a bad thing.

There is one standard library, Phobos, and an alternative, Tango.


> I maintain that D suffers greatly from its lack of a formal specification.

Perhaps, but remember that most languages don't get formal specs until 
long after they become popular. Consider that C++ was defined by cfront 
for the first 10 or 12 years of its existence.


> It is silly for a language as old and relatively popular as D to use a
> compiler written by a small group of people (1 person?) as the official
> reference to the language.

This is not true anymore. Several people are contributing substantial 
upgrades to it. I review everything before they get folded into the 
source tree, of course, but the quality of the submissions has been 
improving by leaps and bounds.


> Not only does the D specification feel really
> unstable,

I admit I'm not good at writing language lawyer text. But the D1 spec 
isn't unstable. The feature set is set, it's pretty clear how it's 
supposed to work, there's a reference implementation to resolve 
disputes, and weaknesses in the spec get fixed.

D2 is a work in progress, and so the spec for it is, too.


> it has a very low bus-factor. In other words: if, hypothetically,
> Walter were hit by a bus, would the D language survive?

With the full release of the source code, and the growth of 
fully-capable third party D compilers, yes it will survive. I couldn't 
wreck the language if I tried <g>.


> D just doesn't offer enough improvements over C++ to make it worthwhile
> switching over. Its design is not very adventurous, keeping simply too
> close to that of the C family, making it look like Yet Another C Language.
> I believe simply filling in the gaps of C++ wasn't enough to take over the
> world. There should have been a greater change.

In my experience, D code is about 30% less source code than the 
equivalent C++. That's a third off of development time, not including 
the debugging time saved. That's a very big deal.

Many valuable improvements of D, such as memory safety guarantees, 
protections against function hijacking, etc., are surely "yeah, yeah, so 
what" unless one has managed large projects and been submarined by these 
problems.

Much of D's improvements appear to be small, but the aggregate is large 
enough that once you write a project in D, you'll find it pretty hard to 
go back to another language.