http://www.reddit.com/r/programming/comments/93jh5/ask_proggit_the_d_programming_language_looks/

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