Reddit: why aren't people using D?

[Michiel Helvensteijn]

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

Then perhaps you can get rid of enum and have only immutable. Well, I'm sure
you have valid reasons to keep it (like actual enumeration). But it would
just seem worthwhile to try to unify them.

> Contracts didn't hit paydirt, and so haven't gotten a lot of follow-on
> attention.

This is too bad. It was one of the features that I liked most about D when I
first started using it.

> and I never heard of ranking functions. 

Yeah, they're called something different everywhere. I've seen them called
loop variants or binding functions. It's the expression that strictly
decreases each iteration and always remains non-negative. The existence of
such an expression proves the eventual termination of the loop.

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

There are many reasons. Some have been floating around this newsgroup this
very day.

* A reference to a function should mean exactly that: a reference to the
function, for use in functional programming. Instead, just the name of a
function now invokes a call.

* In D, &foo returns a function-pointer, but that means that D is context
sensitive, since its subexpression foo would return a property value. It is
confusing.

* What does D do if you have a property (p) that returns a delegate? Will
the call p() return the delegate? Or will it call the delegate?

* writefln = 5; This should just *not* be valid code. But it is.

* Real Properties have many advantages over what looks like D's ad-hoc
solution. They automatically document themselves as properties both to the
programmer and to IDE's (see some other posts from today). The programmer
may use them to overload certain operators and mutator functions that would
speed up the program. Months ago there was a big thread about Real
Properties. I myself offered a suggestion for their design. I don't
remember if you ever responded.

That's just a few reasons right there. D's properties lack elegance and they
lack potential.

>> * No global properties: If I'm not mistaken, global functions can't be
>> properties.
> 
> int foo() { return 3; }
> void main() { int x = foo; }
> works.

Aha. Then you may want to fix the documentation.

http://d.puremagic.com/issues/show_bug.cgi?id=3204

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

Not if commutativity of the * operator is fixed. The documentation states
that * is commutative, which in fact for integers it is. So if I overload *
for matrices, for all the guarantees the docs give me, a D compiler might
choose to swap the operands around (perhaps to get some memory alignment
advantage), and the returned matrix would be incorrect.

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

Well, I suggest that there be NO reverse overloads, that an overload should
be possible in the global scope with the class giving it access to its
private members (C++ uses 'friend', but there must be more elegant ways),
lifting the 'this' restriction that prompted reverse overloads.

I don't know exactly what Koenig Lookup is, but from what I read on
Wikipedia, it involves arbitrary access to other namespaces, which seems
unnecessary. Otherwise it sounds like regular function overloading based on
its parameter types, which D supports, of course.

Though I haven't read it through in detail.

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

I don't know a compelling use-case either. But that doesn't mean there isn't
any. Nor are there any real dangers. Arbitrarily restricting the
possibilities of D doesn't seem like the right way to go.

>> You cannot get a dedicated syntax with library support.
> 
> Of course that's true, but why is a dedicated syntax better than Tuple!(
> ...) ?

See my link just below. If tuples are available in the core language just
like that, people will feel much more comfortable using them in any
situation.

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

http://code.google.com/p/mist/wiki/Tuples

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

Can you allocate stuff on the heap? If not, you can't do proper unit testing
at compile-time.

Perhaps I should have said that the unit-tests should be run automatically
just after compilation and they should not be part of the program
executable. They don't actually need to run 'at compile-time'.

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

It's not. And you understand that the modulo thing is only a symptom, right?
I've found another mistake by accident just today. See the issue report I
filed.

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

I agree. But at least you can count on C++ to do as specified. Where it
doesn't give any guarantees, it specifies that also. With D it's mostly
guesswork and experimentation.

-- 
Michiel Helvensteijn