Games people play

[Lutger]

Georg Wrede wrote:
> Walter Bright wrote:
>>> Many of these features are new to the entire extended language 
>>> family, or have been implemented in radically different ways than 
>>> previously in the extended language family. Are mixins going to cause 
>>> a problem with lambdas? Is liberal use of slices going to make DBC 
>>> unmaintainable? Who knows! Who's going to find out? The early adopters.
<snip>
>> But on the other hand, I don't think this is a reason to be hesitant 
>> to use D. If those more unusual combinations cause a problem, just 
>> don't use them that way. It isn't necessary to remove the features 
>> from the language!
> 
> The C++ guys certainly shouldn't complain, they already do it every day.
> 
> And not using the entire feature set in each source file might be a good 
> idea with any language. :-)

But the C++ guys do complain. For every thread on C++ at gamedev, there 
is no end to the complaints of experienced developers (I'm not counting 
fanboys). Unexpected interactions between features and undefined 
behavior is one source of frustration, what makes C++ complex.

If game developers are to move to a different language than C++, this 
has to be better, not the same. In this light, C# may look more 
favorably to some (indie at least, who don't need to port to all 
platforms). More lightweight, more tools, libraries, company support. I 
think if you want to attract game developers, you will have to compete 
with C# not C++. I'm willing to bet most sane C++ developers are already 
convinced they want to switch language if migration costs permit it.

I don't know if not using features is a valid option, because it's based 
on the premise that it's understood already how exactly they will 
interact with other features, and that 3rd party libraries will not use 
them. Even if this is so, it does increase complexity of development.

Is this viable in a project with, say, half a million lines of code?