Programming Language for Games, part 3

[bearophile via Digitalmars-d]

Walter Bright:

Thank you for your answers.

>> D removes very little bound checks. No data flow is used for 
>> this.
>
> This is false.

Oh, good, what are the bound checks removed by the D front-end? I 
remember only one case (and I wrote the enhancement request for 
it). Recently I argued that we should add a little more removal 
of redundant bound checks. But probably the "GC and C++" mantra 
is more urgent thank everything else.


> This is on purpose, because otherwise about half of what enums 
> are used for would no longer be possible - such as bit flags.

On the other hand we could argue that bit flags are a 
sufficiently different purpose to justify an annotation (as in 
C#) or a Phobos struct (like for the bitfields) that uses mixin 
that implements them (there is a pull request for Phobos, but I 
don't know how much good it is).


>> D module system has holes like Swiss cheese. And its design is 
>> rather simplistic.
>
> Oh come on.

ML modules are vastly more refined than D modules (and more 
refined than modules in most other languages). I am not asking to 
put ML-style modules in D (because ML modules are too much 
complex for C++/Python programmers and probably even unnecessary 
given the the kind of template-based generics that D has), but 
arguing that D modules are refined is unsustainable. (And I still 
hope Kenji fixes some of their larger holes).


>>> - no implicit type conversions
>> D has a large part of the bad implicit type conversions of C.
>
> D has removed implicit conversions that result in data loss. 
> Removing the rest would force programs to use casting instead, 
> which is far worse.

This is a complex situation, there are several things that are 
suboptimal in D management of implicit casts (one example is the 
signed/unsigned comparison situation). But I agree with you that 
this situation seems to ask for a middle ground solution. Yet 
there are functional languages without implicit casts (is Rust 
allowing implicit casts?), they use two kinds of casts, the safe 
and unsafe casts. I think the size casting that loses bits is 
still regarded as safe.


>>> - had a sane macro system
>> There's no macro system in D. Mixins are an improvement over 
>> the preprocessor,
>> but they lead to messy code.
>
> D doesn't have AST macros for very deliberate reasons, 
> discussed at length here. It is not an oversight.

I am not asking for AST macros in D. I was just answering to a 
laundry list of things that C doesn't have (I was answering that 
D doesn't either).


>>> But I guess D already covers it...
>> D solves only part of the problems. And you have not listed 
>> several important
>> things. There's still a lot of way to go to have good enough 
>> system languages.
>
> D does more than any other system language.

Perhaps this is true (despite Rust is more more refined/safer 
regarding memory tracking), that's why I am using D instead of 
other languages, despite all the problems. But fifteen years from 
now I hope to use something much better than D for system 
programming :-)

Bye,
bearophile