Reddit: why aren't people using D?

[Michiel Helvensteijn]

Walter Bright wrote:

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

Aren't immutable and enum the same thing? At least to the programmer?

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

But in C++ you can put a class object on the stack with value semantics,
just as you can put a struct object on the heap. No problem, really. Stack
is default. For the heap, all you need is a pointer.

Personally I hate Java style reference semantics (a.k.a. heap without
pointers). Especially because they also offer a small set of value types,
to confuse matters. Now here's D doing the same thing.

So the solution in D would then be to always use struct? No, because value
semantics seems to come at the price of inheritance. Why? C++ seems to
handle inheritance in value types just fine.

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

Actually, lazy parameter evaluation has its purpose. I personally like
languages in which there are little or no "special constructs" that only
the compiler can provide. In this case, lazy parameter eval could be used
to overload your own short-circuiting operator.

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

I understand why you keep delegates around. I'd just call them function
variables and remove the C(++) cruft. But D's goal is to keep some sort of
backwards compatibility, so ok.

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

Only when you're talking about optimization. There is great value in
automatic proof of correctness. But I know this is a tall order.

> Furthermore, I know of no language other than Eiffel that has all 
> this, and nobody uses Eiffel.

That's a spurious argument. The reason people don't use Eiffel is not its
advanced contract programming features. (It may be the syntax.)

Plus, you ignored the other points. Contract inheritance, 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)
> 
> I don't understand what this means.

Properties. Your syntactic sugar:

int i = c.p; // int i = c.p()
p = i // c.p(i)

They can't do these things:

* No control over their use by class designer: ANY member function with one
or zero parameters may be called using 'property syntax'. This is not a
good thing.

* No way to use +=, -=: I hope this one is clear. The operators that require
both read and write access won't work on properties.

* No global properties: If I'm not mistaken, global functions can't be
properties.

* No parameterized properties: c.f(5) = 6; // c.f(5, 6)

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

Arithmetic like operations like matrix multiplication (which is not
commutative)?

>> confusing rule priority to determine translation,
> 
> The alternative is "Koenig lookup", which I guarantee is far more
> confusing and has many weird problems.

Perhaps you misunderstand. I was referring to the algorithm that first
checks for a complete match, then tries the 'reverse overload', then tries
the commutative call.

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

I can perhaps understand this one. Though I'm sure there are programmers
that'd rather have the ability to overload it.

> For && and ||, they are "short circuit" operators, and how that 
> would sensibly interact with operator overloading I have no idea.

See my comments above about lazy parameter evaluation. I suggest that those
operators are defined with a lazy second parameter for bools, and
programmers should be allowed to overload them for other types as they
please.

> I know of no language that allows overloading && and ||.

C++ does. ! too.

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

You cannot get a dedicated syntax with library support.

I've mentioned I'm working on a programming language myself. I haven't
mentioned its name here, because I didn't think it'd be appropriate. But
with your permission I can post a link to a page describing my tuples.

>> * Unit testing (not at compile time,
> 
> You can do testing at compile time with static asserts.

Not unit testing, surely.

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

Perhaps. But all these available but underpowered features make D look like
a playground rather than a serious language. It's as if you think of a new
feature, try it out for a week, then abandon it (I know, I'm exaggerating).

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

The fact that I want more, but you can't provide it, is a home run? :-)

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

That was then, this is now. In the now, we have a C++ with classes and
templates and a very strict standards committee overseeing its
specification. You want to know why people in the now choose C++ over D?
This is one reason.

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

Yes, but 'pretty clear' does not a spec make. I refer you to our earlier
divide/modulo discussion. You expect programmers that want details to look
at the DMD source code?

And when you change a formal specification, people at least know the
language changes as a result. When you change the compiler, we don't know
if the language has changed or not.

I know that most people can distinguish between a bug and a feature. But
when you want to play with the big boys, you need to make it unambiguous.

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

I don't dispute that most changes D has made to C++ are good, and that the
result is greater than the sum of its parts. And if it weren't for all my
other complaints, this one would not be enough to keep me from D.

-- 
Michiel Helvensteijn