Why D is not popular enough?

Solomon E via Digitalmars-d digitalmars-d at puremagic.com
Sun Aug 21 16:07:43 PDT 2016


On Sunday, 21 August 2016 at 17:26:24 UTC, Walter Bright wrote:
> On 8/21/2016 2:47 AM, ag0aep6g wrote:
>>> Upon use of the value, resolve which type to actually use for 
>>> it. If the
>>> use type requests a type between least and most, use that 
>>> type for
>>> evaluating the entire expression. If the use requests a type 
>>> outside
>>> that range, use the one closest (and, if the use is below the 
>>> range,
>>> complain about narrowing conversion).
>>
>> So when only ubytes are involved, all calculations would be 
>> done on ubytes, no
>> promotions, right? There are cases where that would give 
>> different results than
>> doing promotions.
>>
>> Consider `ubyte(255) * ubyte(2) / ubyte(2)`. If the operands 
>> are promoted to a
>> larger type, you get 255 as the result. If they are not, you 
>> have the equivalent
>> of `ubyte x = 255; x *= 2; x /= 2;` which gives you 127.
>
> That's right.
>
> The thing is, programmers are so used to C integral promotion 
> rules they often are completely unaware of them and how they 
> work, despite relying on them. This is what makes changing the 
> rules so pernicious and dangerous.
>
> I've had to explain the promotion rules to professionals with 
> 10 years of experience in C/C++, and finally stopped being 
> surprised at that.
>
> D does change the rules, but only in a way that adds compile 
> time errors to them. So no surprises.
>
> (Nobody knows how function overloading works in C++ either, but 
> that's forgivable :-) )

I have a speculative answer to the topic of this thread, which I 
was wanting to write a comment here about, before I saw the last 
two comments in this thread.

Look in the D Language Reference, the spec. Look for the word 
"error" there. It occurs many times, in code that is erroneous in 
the spec.

Also, notice the number of question marks in the code sample near 
the end of the page on Declarations. Notice that the questions 
raised are not answered there.

The D spec is full of errors, literally, or teasers sometimes. It 
seems improbable to me that D will become popular unless that is 
first fixed, and the attitude that it represents. It's a sign of 
unsoundness, at least unsoundness about how to teach a language 
or how to standardize it, that comes through clearly at a surface 
level, even if someone doesn't have specific disagreements with 
the design of D.

Erroneous code should be omitted from a spec, or at least clearly 
marked such as by a red background.

Mixing lines commented as errors together with later lines 
commented as "ok" in the same code quote blocks makes it even 
more confusing. (Someone who doesn't know any D yet might even 
think that D gives you the results of whatever lines are correct, 
skipping the errors as if they were empty lines. Programming 
languages differ enough that that's a possible feature, the sort 
of feature that might result in a language being described as 
"exciting" even.)

Anyone feel free to correct me or say I'm all wrong about this. 
I'm not an expert on teaching programming languages. I'm just a 
learner, and just as a hobby.


More information about the Digitalmars-d mailing list