A Perspective on D from game industry

[via Digitalmars-d]

On Tuesday, 17 June 2014 at 16:08:18 UTC, H. S. Teoh via
Digitalmars-d wrote:
> I think you are underestimating the complexity of programming.

No need to go ad hominem. I don't underestimate anything. What
makes you think so?

> Automated
> tools can only go so far -- ultimately, human intervention is 
> needed for
> certain code transformations, and perhaps even that can only go 
> so far,
> because programming is inherently complex!

No more complex then computer assisted proof systems.

> Turing-complete languages
> exhibit unsolvable problems like the halting problem (that even 
> humans can't solve),

How does the halting problem relate to anything practical? It's a 
fun example of a proof where you reason about one infinite 
dimension being larger than another infinite dimension, but that 
is about all it provides.

> besides also exhibiting intermediate intractible
> complexities like non-primitive-recursive functionality and the
> expression of NP-complete problems that are inherently 
> irreducible to simpler constructs.

Most NP-complete problems are NP-complete because they are
expressed as a decision problem (boolean function). The moment
you take the quantifiable sub problem and formulate it as
something reasonable it often seize to be NPC.

You almost never want an optimal result, you want a good result
that require less resources. NPC is a funny construct, but
reasoning about NP-hard problems has very little practical value
and that's the only thing NPC is good for.

NPC has little to do with automated code translation. E.g. if you
for some reason want to remove all "while(){}" loops you can
easily replace them with "if(){do{}while()}".

> around, etc.. So this part is easily automatable. But I think 
> you're
> deceiving yourself if you think that automation is possible 
> beyond the
> trivialities of programming.

Gofix worked out ok in a macro-free environment.

It cannot work in a macro-heavy environment.

Of course, code transformations is easier in a pure functional
language, but that does not change the fact that having a
transformation-friendly imperative language is desirable.