Michiel Helvensteijn escribió:
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.
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.
D offers too many ways to do the same thing:
* const, enum, immutable, invariant
Agree.
* structs, classes
Don't agree. It's nice to have this distinction when you care about
performance. I just removed a class from a Java project and replaced it
with a pair of parameters because too many instances of it were created.
If I had structs in Java I woudln't have that problem. C# also has them
and it's ok.
* functions, delegates, lazy parameter evaluation
* garbage collection, manual D memory management, manual C memory management
It's ok if you want to have finer control over the memory. Not
everything is high-level.
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.
D offers some cool features, but leaves them very underpowered:
1. Contract programming (no contract inheritance, no compile-time static
analysis, no loop invariants / ranking functions)
2. Class/Struct properties (no control over their use by class designer, no
way to use +=, -=, no global properties, no parameterized properties)
3. Operator overloading (no fine control over comparison operators, fixed
commutativity, confusing rule priority to determine translation, no
overloading of !, &&, ||, <>=)
4. Tuples (no dedicated syntax, no parallel assignment, no non-flattening
tuples without workarounds, no returning tuples)
5. Unit testing (not at compile time, not possible to categorize)
6. 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.
It's amazing how many times 2, 5 and 6 were mentioned in this newsgroup.
However nothing is done in this respect (maybe for 6 yes, but I think
phobos should just dissapear).
I maintain that D suffers greatly from its lack of a formal specification.
For me, it's not the lack of a formal specification, but it's hard to
find how something works. Navigating the site is a PITA.
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. Not only does the D specification feel really
unstable, it has a very low bus-factor. In other words: if, hypothetically,
Walter were hit by a bus, would the D language survive?
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.
