Programming Language for Games, part 3

[bearophile via Digitalmars-d]

Walter Bright:

> I don't see the use cases, in mine or other code.
> Designing a language feature around printf is a mistake.

I agree. Let's talk about other use cases.


> I've considered the feature, and looked at code. It just 
> doesn't happen very often.

I have written plenty of D code (perhaos 240 thousand lines so 
far) and I've seen several cases where the ideas I've suggested 
can be useful.

If you define a rangedInt struct:

void main() {
     alias I10 = rangedInt!(int, 0, 10);
     I10[] arr = [1, 5, 12, 3];
}


My ideas should be able to spot the bug in that array literal at 
compile-time. Ada2012 is able to do the same. Currently D can't 
do that.

The same is possible with other values, including complex ones as 
kinds of game data. If I define a finite state machine the enum 
precondition is able to spot malformed machines at compile time. 
I am able to give you more usage examples on request.

It happens often enough to justify a similar feature in Ada2012. 
(This is the main point of this whole discussion. The other parts 
of this answer are less important).



> All features have a cost/benefit to them. The costs are never 
> zero. Laying on more and more features of minor benefit will 
> destroy the language, and even you won't use it.

I agree. But freezing D design is not a good idea. (Note: so far 
I don't care for C++ interoperativity much. And I think the a 
good way to face GC-derived problems is to introduce memory 
ownership tracking in the type system).


> Oh come on. writefln is typesafe and will not crash.

It shows bugs at runtime, where they can be avoided (turning them 
to compile time ones) at essentially no cost for the programmer. 
For me this is a broken/unacceptable design (and I'm saying this 
since years. Glad to see Rust people agree. I think this is an 
example of this phenomenon: 
http://en.wikipedia.org/wiki/Punctuated_equilibrium  in the 
programming language design world).


> You could also write:
> 
>    formattedwrite!"the format string %s %d"(args ...)
> 
> if you like. The fact that nobody has bothered to suggests that 
> it doesn't add much value over writefln().

Plenty of people have bothered, there's an implementation.


> It does some flow analysis based on previous bounds checks.

I didn't know this. I'll need to do some experiments :-)


>> 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).
>
> More annotations => more annoyance for programmers. Jonathan 
> Blow characterizes this as "friction" and he's got a very good 
> point. Programmers have a limited tolerance for friction, and D 
> must be very careful not to step over the line into being a 
> "bondage and discipline" language that nobody uses.

The annotation is used only once at the definition point of the 
flags. So the "annotation" here is essentially a way to tell the 
compiler that you don't want a regular enumeration, but a flags. 
It's like having two different language constructs, enums and 
flags. So it's a way to offer the programmer a chance to express 
intent and make the code more expressive/readable. And this 
allows to make the semantics of enums more strict. It's a 
win-win-win situation. The real downside is increased language 
complexity, but as I explained in past, well designed clean 
features are not the main source of complexity. And formalizing a 
programmer idiom is often not a bad idea.


> I don't buy the notion that more complex is better. Simple and 
> effective is the sweet spot.

I am not asking for ML-style modules in D. But ML modules aren't 
complex for free, they introduce important qualities in ML 
language and its "generics".


> It is not suboptimal.
> D is at a reasonable optimum point for this.

In my opinion it has some faults. I am not alone with this 
opinion. So I think it's not at the optimum.


> There are lot of tradeoffs with this, and it has been discussed 
> extensively.

I agree, but the situation is not improving much so far. I see 
mostly stasis on this.


> The implication that this is thoughtlessly thrown together 
> against all reason is just not correct.

I didn't say D implicit casts are randomly designed :-) I said 
that they are currently not very good or the best possible.


>> I think the size casting that loses bits is still regarded as 
>> safe.
> It is memory safe.

Probably that's why there are two kind of casts in Haskell.

Bye,
bearophile