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
* structs, classes
* functions, delegates, lazy parameter evaluation
* garbage collection, manual D memory management, manual C memory management
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:
* Contract programming (no contract inheritance, no compile-time static
analysis, no loop invariants / ranking functions)
* Class/Struct properties (no control over their use by class designer, no
way to use +=, -=, no global properties, no parameterized properties)
* Operator overloading (no fine control over comparison operators, fixed
commutativity, confusing rule priority to determine translation, no
overloading of !, &&, ||, <>=)
* Tuples (no dedicated syntax, no parallel assignment, no non-flattening
tuples without workarounds, no returning tuples)
* Unit testing (not at compile time, not possible to categorize)
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.
I maintain that D suffers greatly from its lack of a formal specification.
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.
--
Michiel Helvensteijn

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

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.

On Wed, Jul 22, 2009 at 5:10 PM, Michiel
Helvensteijn<m.helvensteijn.remove@gmail.com> wrote:
> 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.
Ha. Had D differed *too* much from C++, then we'd run the risk of
scaring off the C++ snobs simply because it wasn't familiar enough to
them.
You can never please C++ users with another language. Let's not get
hung up on attracting them.

On Wed, Jul 22, 2009 at 6:30 PM, Walter
Bright<newshound1@digitalmars.com> wrote:
> 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.
This is EXACTLY the point I always try to make to newcomers. It's so
significant that I think it should be on the front page of the
language spec, in bold, 72 point, red letters.

On Wed, Jul 22, 2009 at 3:59 PM, Jarrett
Billingsley<jarrett.billingsley@gmail.com> wrote:
> On Wed, Jul 22, 2009 at 6:30 PM, Walter
> Bright<newshound1@digitalmars.com> wrote:
>
>> 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.
>
> This is EXACTLY the point I always try to make to newcomers. It's so
> significant that I think it should be on the front page of the
> language spec, in bold, 72 point, red letters.
Yeh, it's like what's the big diff between a Lamborghini and a Chevy
Nova anyway? They both have four tires. They both run on gas. So
what's all the fuss about the Lamborghini?
--bb

On Wed, Jul 22, 2009 at 06:59:45PM -0400, Jarrett Billingsley wrote:
> On Wed, Jul 22, 2009 at 6:30 PM, Walter
> Bright<newshound1@digitalmars.com> wrote:
>
> > 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.
>
> This is EXACTLY the point I always try to make to newcomers.
Agreed. This is the big benefit, but the hard part is that it takes some
experience to really realize it.
How can we sell that to someone who doesn't have that experience using it?
"Just take my word for it" doesn't mean much when coming from strangers on
the Internet, or from the site's homepage.
--
Adam D. Ruppe
http://arsdnet.net

Jarrett Billingsley wrote:
> Ha. Had D differed *too* much from C++, then we'd run the risk of
> scaring off the C++ snobs simply because it wasn't familiar enough to
> them.
It's a good point. Radically different languages tend to fail simply
because few are willing to expend the effort to learn it. This is why
Haskell will never catch on.
> You can never please C++ users with another language. Let's not get
> hung up on attracting them.
C++ will be around and will be used as long as any of us are alive, no
matter what. It's just a fact of life.

On Wed, Jul 22, 2009 at 4:19 PM, Adam D. Ruppe<destructionator@gmail.com> wrote:
> On Wed, Jul 22, 2009 at 06:59:45PM -0400, Jarrett Billingsley wrote:
>> On Wed, Jul 22, 2009 at 6:30 PM, Walter
>> Bright<newshound1@digitalmars.com> wrote:
>>
>> > 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.
>>
>> This is EXACTLY the point I always try to make to newcomers.
>
>
> Agreed. This is the big benefit, but the hard part is that it takes some
> experience to really realize it.
>
> How can we sell that to someone who doesn't have that experience using it?
>
> "Just take my word for it" doesn't mean much when coming from strangers on
> the Internet, or from the site's homepage.
Even that does have a cumulative effect, though. If you keep hearing
"take my word for it" from different sources, eventually, if you have
any curiousity at all, you'll want to check it out for yourself.
--bb