Why I (Still) Won't Use D

[Benji Smith]

I first stumbled across the D programming language way back in 2002.

For a few years, I was active in all of the newsgroup discussions, and I 
spent a significant proportion of my spare time tinkering with D library 
development (I actually wrote an XML parser in D back in early 2003).

At that time, Phobos was still pretty slim (and there was no Tango), so 
the language didn't have a standard library that could really support 
application development. And there was no support for D in IDEs or 
debuggers.

And there were a few pesky language issues that irked me (no boolean or 
string types, for example), and a fair handful of compiler bugs that 
needed to be fixed.

But the language was *ALMOST* ready.

And I was excited for a syntactically simple, 
semantically-straightforward development language that compiled to 
native machine code. On windows, linux, or mac!! Hooray!

Although my active participation in the community evaporated when my 
kids were born (premie twins who spent 4 months in the ICU with a 
laundry-list of complications), I've continued to regularly lurk here 
for the last six years.

Over that time, the tools and infrastructure surrounding D have improved 
vastly. Tango is a spectacular piece of work. DSource is very 
impressive. The available libraries are maturing nicely. The compilers 
are much more robust. Lots of things about D are looking very compelling.

There's a new project on my plate right now. I need to produce native 
binaries, with C bindings. It needs to run on win/linux/mac. And it 
needs to be small and lightweight (though not necessarily blazingly fast).

It seemed like the perfect opportunity to give D another shot.

So I dove back in and read through the docs, and I've been reading 
*everything* on the NG for the last month or so. I've been reading 
tutorials and browsing through code repositories.

And, I'm sorry to say, the language itself has seriously degraded, even 
while the libraries and tools have improved so much.

It's very disheartening.

Here are some of the things that are most offputting:

CONST

Const is a total trainwreck, and is the biggest reason for me to stay 
away from D in a real project. Even now, nearly a year after the 
introduction of const/final/invariant, there are still NG threads with 
more than a hundred posts with people trying to understand how const is 
supposed to work and how they can accomplish (really simple) goals under 
the current const regime.

Before the advent of the various const implementations, I could glance 
at a function declaration and know exactly what it meant. Now it takes 
much more effort to understand even the most const-aware functions and 
develop a strategy for working with them in an application.

Even if I liked the current semantics, everything still seems so 
up-in-the-air with const, I'd be loathe to dive in until it stabilized. 
And I don't see that happening anytime soon.

It seems like most of the people weighing in on the const debate are 
trying to figure out a type system and a set of operations that will 
support all possible use cases. (Like the recent "const debacle" thread.)

It seems like const will either become too complex for ordinary usage 
(and will be worked-around more often than used properly) or it will 
become too weak to be enforce absolute safety/optimization guarantees.

Personally, I'd rather have no concept of const at all than adopt any of 
the implementations that have been proposed so far.

STRINGS

The existence of three different string types (six, if you count 
const/mutable variations of each) makes text-processing more difficult 
than it ought to be.

I would have liked to see just one string type, with encoding kept as an 
internal implementation detail. And I'd much rather have a string class 
than to treat strings as character arrays (especially since 
indexing/slicing deals with code-points rather than character positions).

KEYWORD OVERLOAD

The mandate to keep keyword count as low as possible has been a real 
detriment to the language.

Each unique concept should have its own unique keyword.

As I've been trying to learn the language, it's easy to get confused 
when a keyword takes on multiple different meanings, depending on its 
context. For example, although I've kept casually following this NG for 
all this time, I've never fully grokked all the different meanings of 
"static".

ARRAYS

1) There's a gap in functionality between static arrays (whose size must 
be known at compile time) and growable dynamic arrays.

Most often, what I really want is a non-growable array whose size isn't 
known until runtime, but D doesn't have that concept (Java and .NET have 
it). And the disparity between the static & dynamic array types (which 
are fundamentally different in the type system) means I can't write code 
like this:

   int[] doSomething(int[] array) { ... }

   int[4] a;
   int[] b;

   // Inplicit conversion. Does this copy data?
   b = doSomething(a);

   // Error: functions can't return fixed-length arrays!
   a = doSomething(b);

That's really too bad. The type system really should treat an int[] and 
an int[4] as the same type. If the compiler wants to optimize certain 
static arrays by putting them in the data section of the compiled OBJ, 
when possible, that's fine by me. But having that behavior affect the 
type system is a pain in the neck.

I also would have preferred to have growable arrays and associative 
arrays in the standard library than in the language. A more unified 
array syntax could get rid of some nasty warts like this:

   // Doesn't compile
   char[][] words = [ "hello", "world" ];

   // Compiles, but the only way to know about this trick is by asking
   // someone for help in the NG.
   char[][] words = [ "hello"[], "world" ];

   // Would be ideal. Growable arrays would be best implemented as a
   // templatized collection class.
   List!(String) words = [ "hello, "world" ];

2) An empty array is equal to a null pointer. Yikes!

3) Array syntax should support both multi-dimensional arrays and jagged 
arrays:

   int[,] multidim = new int[4,5];
   int[][] jagged = new int[4][5];

ANYHOW...

There are lots of other little annoyances, but those are the biggest 
things I can think of right now.

For me, the D language is becoming less and less compelling as time 
passes. I have a hard time wrapping my mind around all the keyword 
ambiguities, let alone the little quirks necessary to keep the compiler 
happy. And the const semantics don't seem anywhere near a resolution.

I feel like, if I'm going to use such a complex language, I may as well 
choose C++, which offers the advantages of ubiquity and language stability.

Nevertheless, the things that keep me interested in D are:

* Multi-platform, compiled to machine code. No VM required.

* No header files.

* No preprocessor.

* Built-in garbage collection.

* Real structs

* Semantic import, rather than lexical #include.

* No need for forward declarations.

* Single inheritance, and interfaces.

But whenever I've come back to give D another look, the weaknesses 
always outweigh the strengths. I don't want to memorize a bunch of 
loopholes. I want a straightforward language that makes sense, right out 
of the box.

(Incidentally, most of my development work over the last few years has 
been in statistical machine learning, vector-space information modeling, 
agent-based simulation, and domain-specific language compilers.)

I know this is a really long message, but I wanted to provide some 
feedback about why -- after all these years -- D is still not an option 
for my development projects. And that's in spite of me really *wanting* 
something that follows the original, core D design principles.

Cheers,

--Benji Smith