
Special Cases Are a Code Smell - hyperpallium
https://lobste.rs/s/opy2ay/special_cases_are_code_smell
======
hyperpallium
The first e.g. is relevant to water simulation/CFD, where you estimate
derivatives from neighbours. I kinda dislike the (popular) solution of
padding, because performance is always an issue, and I don't like wasting
memory (worse in a grid), even if maybe it doesn't really matter.

But in CFD, confirming your code is correct can be an issue... There's no
formula to check your results against (notwithstanding MMS); flows can be too
complicated to tell by eye if they are correct; and intrinsic discretization
and round-off errors mean it can _never_ actually be correct anyway. So
anything to reduce silly coding errors has got to be a good thing!

These contradictory goals of correctness and performance can be accommodated
with two versions: a correct one, to check a performant one.

aka make it right, _then_ make it fast; optimization laws: (1) don't (2) not
yet

But in general, I think: If it _feels_ like a special case, make it _look_
like a special case. If the next developer must first be educated about the
whole problem, your theory of it, your solution and implementation, it's a
_Barrier of Abstraction_. The last example in the article is very clever,
perhaps... too clever. Debugging it might be tricky.

OTOH If your theory really is _really good_ , pretty soon everyone will "feel"
in terms of it, and the special case will disappear. e.g. relational algebra,
structured programming, modules, objects, fp

\tangent an efficient approach to the 1st example is a running sum: to move
right, add the entering cell, and subtract the exiting cell. (2 ops per cell
instead of 3)

~~~
hyperpallium
PS of course, in order to pad, you don't need to transform (copy into a new,
wider array) - you can use the wider array in the first place.

