Programming Language for Games, part 3

[bearophile via Digitalmars-d]

Walter Bright:

> Why aren't you using Ada if this is critical to you? (I'm not 
> being sarcastic, this is a fair question.)

It's not critical...
Ada is not fun, too much new stuff to learn and to adapt to, and 
I can't influence Ada evolution in any way. My hope for preferred 
future system language is not in Ada. Still, Ada contain some 
nice ideas.


> I'm not saying "freeze the design".

But we are currently close to this... Lately the only ideas I've 
seen seriously discussed are the ones about reference counting by 
Andrei. Even the proposal about the tracking of memory ownership 
was not much discussed.


> I'm saying that if things are wrapped in enough bubble wrap, 
> few programmers will want to use the language. After all, I 
> don't wear a firesuit or helmet when I drive my car.

The new pre-condition is optional (you use it for Phobos structs, 
etc), and for the programmer that later uses the 
function/struct/class its usage its totally transparent, so the 
wearing of firesuit/helmet metaphor is not good enough.

If I define a library type named Nibble that is represented with 
an ubyte and accepts only values in [0, 15] with an enum 
precondition, I can use it like (once Kenji patch to convert 
arrays of structs is merged):

Nibble[] arr = [5, 18, 3, 1];

The usage is totally transparent for the user, no firesuits or 
helmets are necessary or visible (yet that code will give a 
compile-time error).


> I understand. But poor C++ interop is preventing quite a few 
> people from using D.

I understand and I encourage this part of D design to keep going 
on.


> Validating printf format strings is not.

I don't care much of printf/writef. That was just an example, and 
not even the most important.


> 2. If it exists, why aren't you using it?

If a writeln template with compile-time format string testing 
goes in Phobos I'll surely use it (despite the template bloat it 
will cause).


> I understand that - yet another basic type in the system.

Perhaps a good enough FlagsEnum can be implemented with pure D 
library code.


>> And formalizing a programmer idiom is often not a bad idea.
>
> Sorry, this is just hand-waving.

I have seen it's often true ::-) New languages are essentially 
invented for this purpose: to turn programmer idioms into 
compiler-enforced features with a short nice syntax. The idiom of 
passing a pointer + length to a C function is replaced by a much 
better dynamic array of D. Even OOP is an idiom that used to be 
implemented badly in C by lot of people. This list of examples 
can become very long.


> A reasonable optimum point is not equal to "nobody can find any 
> fault with it". A reasonable optimum point is where the faults 
> are more acceptable than the known alternatives.

I think the free mixing of signed and unsigned integral values is 
not a good idea in D. I think that there are various ways to 
refine immutable value range propagation.

Bye,
bearophile