Reddit: why aren't people using D?

[Walter Bright]

Michiel Helvensteijn wrote:
> Aren't immutable and enum the same thing? At least to the programmer?

Not at all. How would you declare a type that is "pointer to immutable 
int" using an enum? Anyhow, there was a looong thread about this a year 
back or so.

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

It may indeed be the syntax, but consider that no other language adopted 
those constructs. There was a proposal to add contracts to C++0x which 
died. I added them to Digital Mars C++ and nobody cared.


> Plus, you ignored the other points. Contract inheritance, loop invariants,
> ranking functions.

Contracts didn't hit paydirt, and so haven't gotten a lot of follow-on 
attention. Eiffel has contract inheritance, I think it has loop 
invariants, and I never heard of 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.

Why not? Seriously, what is the semantic difference?

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

Agreed that's a problem. Andrei has also been a strong advocate of 
fixing it.


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

int foo() { return 3; }

void main()
{
     int x = foo;
}

works.


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

Ok.


>>> * 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)?

I believe this is completely controllable with D.


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

I did understand it. The alternative is Koenig Lookup, and the reason 
for its existence. Reverse operator overloading is a bit awkward, but 
the awkwardness is restricted to the class in which it appears. ADL 
(Koenig Lookup) spreads awkwardness everywhere.


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

I'm sure there are, too. That doesn't mean it's a good idea! Features 
ought to have compelling use cases for them, not just it-would-be-nice-if.


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

Oops, you're right. Here's an old thread about it: 
http://www.digitalmars.com/d/archives/digitalmars/D/18153.html

I can't recall ever seeing anyone use it, though. Until there's a 
compelling use case for it, not just it being a nice idea, I'll stick 
with my belief it's a bad idea.


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

Of course that's true, but why is a dedicated syntax better than Tuple!( 
...) ?


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

Sure.


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

You can use static asserts to, at compile time, check the result of any 
computation, including function calls, that the compiler is able to 
execute at compile time. It sounds perfectly usable as unit tests to me, 
and in fact I do use static assert that way.



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

I replied more on unit testing in another response in this thread.


> Yes, but 'pretty clear' does not a spec make. I refer you to our earlier
> divide/modulo discussion.

We're going to fix the modulo thing. But the C++ standard leaves it 
implementation defined. How is that better?

And how about the C++ source character set and the behavior of "char"? 
It's a standardized specifying of a mess of implementation defined and 
undefined behavior.

Sure, the D spec has gaps in it. But the C++ standard also has large 
gaps of uselessness in it.