View mode: basic / threaded / horizontal-split · Log in · Help
July 22, 2009
Reddit: why aren't people using D?
http://www.reddit.com/r/programming/comments/93jh5/ask_proggit_the_d_programming_language_looks/
July 22, 2009
Re: Reddit: why aren't people using D?
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
July 22, 2009
Re: Reddit: why aren't people using D?
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.
>
July 22, 2009
Re: Reddit: why aren't people using D?
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.
July 22, 2009
Re: Reddit: why aren't people using D?
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.
July 22, 2009
Re: Reddit: why aren't people using D?
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.
July 22, 2009
Re: Reddit: why aren't people using D?
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
July 22, 2009
Re: Reddit: why aren't people using D?
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
July 22, 2009
Re: Reddit: why aren't people using D?
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.
July 22, 2009
Re: Reddit: why aren't people using D?
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
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home