Re: [dev] Suckless design in Games

On Wed, Aug 11, 2010 at 1:05 PM, Szabolcs Nagy <nsz_AT_port70.net> wrote:
> i experimented with various types of genericity for algorithms
> here is one approach:
> implement the algorithm in the simplest way for the most useful types
> etc. then when you need it for a specific task then copy the code and
> apply appropriate modifications in the source (often s/type1/type2/g)
>
> it turns out that with this approach it's often easier to change
> a component without screwing things up than by understanding all
> the gory details of a generic api like boost
>
> adapting an algorithm for your usecase usually takes less than an hour
> and the result is readable customized code, easy to debug, easy to edit

I spent a while working for a company that used that philosphy (albeit
in Matlab). As someone who didn't write the original algorithms (so I
didn't have the slowly accumulated knowledge from having been the one
who wrote them) it was a complete nightmare because there were various
implementations of a basic algorithm, all different subsets of the
bugs that had ever existed in the algorithm development depending on
when and who they'd branched from. Worse, once this had been done for
a while the using code sometimes grew to depend on some of the "bugs"
(rather than biting the bullet and consolidating them and dealing with
the fallout) so you had to basically keep in mind what peculiarities
this particular implementation of the algorithm had (which of course
was always from memory because even in this case, the original code
writers frown on you putting comments about what bugs their code has).
And of course, because "if you can't see that the code has broken,
don't poke it" when a bug was fixed in one implementation the other
implementations weren't checked whilst memories were fresh. Unified
implementations would have required more up-front work, but would I
think have been less work overall. (The people who had actually
written the rats maze of code disagreed; it's difficult to see how
much was partly because it was their baby.)

All of your points have some validity, but given the choice between
one algorithm implementation with a complex BUT EXPLICIT API and
multiple "implementations of some algorithm that does something along
these lines" with simple APIs, personally I'd take the one
implementation.

-- 
cheers, dave tweed__________________________
computer vision reasearcher: david.tweed_AT_gmail.com
"while having code so boring anyone can maintain it, use Python." --
attempted insult seen on slashdot