Programming Language for Games, part 3

[Walter Bright via Digitalmars-d]

On 11/2/2014 5:44 AM, bearophile wrote:
> 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).

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


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

I'm not saying "freeze the design". 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.


> (Note: so far I don't care
> for C++ interoperativity much.

I understand. But poor C++ interop is preventing quite a few people from using 
D. Validating printf format strings is not.


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

1. I've heard proposals, but no implementation.
2. If it exists, why aren't you using it?
3. It is obviously doable in D. No language extension required. You can even 
write one and contribute it!


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

I understand that - yet another basic type in the system. I believe you majorly 
underestimate the costs of these things, or even assign zero cost to them.


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

Again, you badly underestimate the costs or just pretend they aren't there.


> The real
> downside is increased language complexity, but as I explained in past, well
> designed clean features are not the main source of complexity.

I must ask, have you ever designed a house? Everything is a tradeoff. Want a 
bigger closet? What becomes smaller as a result? Do you want a view from the 
kitchen window or do you want a convenient door from the kitchen to the garage? 
If you give the view to the kitchen, are you willing to give up the view from 
the study? Do you accept this change will add $10,000 to the budget? This other 
change will require approval from the zoning people, causing delays. How will 
the position of the windows make the house look from the street? And on and on.

Language design is the same thing. You can't just "explain" that the solution is 
to make "clean" features. Like a house design, every feature in a language 
interacts with every other feature.


> And formalizing a programmer idiom is often not a bad idea.

Sorry, this is just hand-waving.


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

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.


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

I strongly reject that notion.


> or the best possible.

It's the best anyone has come up with for now.


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

     x & 0xFF

loses bits as well. What do you propose to do about that flaw?