The analogy to math always lingers in my mind: before we had efficient, well-understood formulas, we would always rely on lookup tables to solve real problems.

The analogy to math always lingers in my mind: before we had efficient, well-understood formulas, we would always rely on lookup tables to solve real problems. True of construction in ancient Egypt - also true of many programming problems today. I got into an argument the other day about the idea of using fewer names for things in code - I wasn't doing a stellar job of articulating the point since the obvious rebuttal is "if you aren't using a name what are you going to use instead?" But it happens so often that what you are - or should be - implementing is not a business rule, but supporting computation - and in the latter, naming is relatively unimportant. And when you do finally reach business logic, it turns out to flow more smoothly if you allow a procedure to be a complex "train station" or "Manhattan Island" and don't carve it up unnecessarily, because more is done with fewer variables or more obviously short-lived and temporary variables. Fewer things get passed around, thus fewer things need names. And the code is generously imperative but can be understood because a top-to-bottom reading is possible. Using more table-driven code just happens to be one particularly effective way of streamlining logic and named fields out - it's more effective than most uses of OO abstraction because it is a concrete specification of possibilities, yet it doesn't preclude extension in any dimension.