A Perspective on D from game industry

[H. S. Teoh via Digitalmars-d]

On Wed, Jun 18, 2014 at 02:18:47AM +0000, c0de517e via Digitalmars-d wrote:
> On Wednesday, 18 June 2014 at 01:46:02 UTC, H. S. Teoh via Digitalmars-d
> wrote:
> >On Wed, Jun 18, 2014 at 01:21:34AM +0000, c0de517e via Digitalmars-d
> >wrote:
> >[...]
> >>I don't doubt that there are forms of metaprogramming that are MUCH
> >>better than C++, actually C++ is among the worst. But even in dunno,
> >>a lisp with hygienic macros, metaprogramming should be used imho
> >>with caution, because it's so easy to introduce all kind of new
> >>constructs that look nifty and shorten the code, but one has to
> >>understand that each time you add one it's one more foreign syntax
> >>that is local to a context and people have to learn and recognize
> >
> >Isn't it the same with having many different functions that do almost
> >exactly the same thing? You're just shifting the context dependency
> >onto the additional cognitive load to remember and recognize all
> >those little variations on the same abstract operation -
> >findInIntArray, findInStringArray, findInFloatArray, findInIntTree,
> >findInFloatTree, findInStringTree, etc.. Why not rather combine them
> >all into a single find() function that works for all those cases?
> >
> >Not to mention, having to separately implement findInIntArray,
> >findInFloatArray, findInDoubleArray, etc., just increased the amount
> >of almost-duplicate code n times, which means n times more
> >opportunities for typos and bugs. As we all know, humans are very
> >error-prone, so minimizing the opportunities for error is a
> >significant benefit.
> >
> >And arguably, the metaprogramming solution actually *reduces* the
> >amount people need to learn and recognize, because you learn the
> >abstract operation "find" once, and then you can apply it to all
> >sorts of containers (as long as the find() implementation supports
> >the underlying concrete types). Without metaprogramming you have to
> >implement find() n times, and the people who come after you have to
> >learn it n times.
> >
> >Now, granted, it *is* possible to abuse metaprogramming by having the
> >int overload of find() do something completely unrelated to the float
> >overload of find(), like one returning the first matching element and
> >the other returning the last matching element, but that's a problem
> >caused by the improper use of metaprogramming, not an inherent
> >problem of metaprogramming itself. You can't blame a hammer for not
> >being able to hammer a nail just because somebody decided to use the
> >wrong end for hammering.
> >
> >
> >T
> 
> Now you're talking polymorphism again, but I already said polymorphism
> is rather ok, and it's actually not really metaprogramming, it's just
> fancier typing.

Actually I was talking about templates:

	R find(R,T)(R range, T element)
		if (isInputRange!R && is(ElementType!R : T))
	{
		while (!range.empty)
		{
			if (range.front == element)
				break;
			range.popFront();
		}
		return range;
	}

That's a template function that searches an arbitrary input range for
arbitrary element type. It captures the essence of linear search in a
generic form, and thereafter you never have to write linear search
again, you just implement types that conform to the input range API
(i.e., with .empty, .front, .popFront members with the appropriate
semantics), or appropriate helper functions on native types, and call
find() on it. It can search arrays of any type, linked lists, input
streams, network sockets, *any* type that implements input range
primitives.

Without metaprogramming, you'd have to implement n versions of find()
for arrays -- one for each element type you'd want to support, n
versions for linked lists, n versions for network sockets, etc., with
k*n opportunities for bugs, typos, and boilerplate.

Is this the kind of metaprogramming you're referring to, or did you have
something else in mind?


T

-- 
Recently, our IT department hired a bug-fix engineer. He used to work for Volkswagen.