

This is gonna make me sound crazy, but always pass functions when possible, and use case statements for how the passed-in functions are applied.
As a simple example, imagine you want to take the average of a set of numbers. Instead of doing sum(numbers)/len(numbers), do:
Quotient_reduce(sum, lambda x,y: x+1, numbers)
then, inside the definition of quotient_reduce,
Def quotient_reduce(accumulate_by, normalize_by, list):
If accumulate_by==sum and normalize_by==(lambda x,y:x+1):
return [some efficient implementation of average]
Else:
Return reduce(accumulate_by, list)/reduce(normalize_by, list)
I know it must look insane, but it generalizes normalization, mean, geometric mean, etc, and on the outside there’s no taste of the horrible concrete implementation!
Apologies about formatting, I’m on my phone.

It has to do with how you decompose problems. In the example I gave, I was trying to point out that arithmetic average, geometric average, and normalization are related problems. Consider applying this technique to something more complicated than averages: pathfinding. You could create a dozen different efficient functions, each with different considerations, but the core of the algorithm will always be the same. You can write pathfind_land(src, dest), pathfind_sea(src, dest), pathfind_air(src,dest), pathfind_sea_and_land(src,dest) etc. but it’s obviously better to write it as pathfind(src,dest, is_traversable) and select the most efficient implementation inside the function. It also allows you to use a not-optimized implementation automatically if you haven’t made an efficient implementation.