A Perspective on D from game industry

[c0de517e via Digitalmars-d]

> You don't need metaprogramming to have this problem.
True, in fact it was an example of a more general idea.

> There was also the complaint from some developers that C is
> "superior" to C++ because in C++, a method call in a complex 
> class
> hierarchy can theoretically end up "anywhere", whereas in C, 
> you at
> least know exactly which function will get called, since there 
> is no
> overloading.

That's an extreme opinion, tools are tools, it's not that we 
always have to operate in the strictest ways possible, but yes 
I'd say you have to be conscious of the consequences.
Nowadays my rule of thumb is to ask myself -do I need this- when 
thinking of grabbing a given language feature for a given 
implementation. Do I need a class? What would it give me? If it 
ends up with considerable savings then go ahead.

> Now you discover a bug somewhere in this function. How would 
> you go
> about finding where it is? Well, since this is C, which 
> allegedly
> doesn't have any polymorphism, that should be trivial, right? 
> Just trace
> through all of the function calls and narrow it down. Except... 
> all of
> those ops.xxx() calls are function pointers. So OK, we need to 
> find out
> where they point to.

Yeah... That decision was quite bad (especially today!), as you 
point out they didn't avoid polymorphism really, just 
re-implemented it in a language that doesn't support it natively 
in its type system, and that is often trouble.

That's why I actually am wary of certain forms of 
metaprogramming, I don't think it's often a good idea to try to 
extend a language beyond what its syntax natively supports, not 
only because it surprises people, but also because it will 
surprise tools and so on...

> [...] you only
> need to remember add and delete, and the abstraction takes care 
> of
> itself by resolving to the correct overload based on the 
> argument types.

That is not really OO though or well not what I mean with OO/OOD. 
The OO that I would avoid is the "thinking in objects" mindset.
Associating functions with types is the simplest form of 
polymorphism and it's totally fine, you don't even need classes 
for that! But even if you face a problem where you do actually 
need interfaces over objects, go ahead, I'm not saying it's never 
useful. But it shouldn't be the "default" state of mind and 
certainly how to split computation in objects shouldn't be the 
way we think about solving problems, that's the bad of OO 
mentality that degenerated into horrors like "patterns". 
Computation is algorithms that change bits of data.

> Metaprogramming goes one step further and lets you reduce 
> boilerplate --

True, I just wanted to show the tradeoff that are entailed in 
that. Then it can still be useful, but a lot of times is just 
abused, and many, many times we would be better served by a 
better type system than having to hack features via 
metaprogramming.

I would be much more open to generics if we had in C++ bounded 
parametric types (concepts... or C# style generics) rather than 
templates. And I would use C++11 lambdas, even if I wouldn't have 
touched with a mile-long pole the Boost::lambda stuff, and so 
on...

>
> At the end of the day, *all* tools must be used with care. Even 
> in C, a
> language with neither OO nor metaprogramming support, you can 
> code
> yourself into a nasty mess by using built-in language 
> constructs like
> function pointers, like I showed above. Just because you *can* 
> cause
> serious injury to yourself with a hammer, doesn't mean that 
> hammers
> are inherently evil.

Right, but we live in a world where it seems to me lots of people 
are hammer happy :)