Do programmers put everything they know about a problem domain into the code they write to solve that problem? Or do they instead select a relatively parsimonious subset of that knowledge to define formally and translate into code? If the latter is true, it may be that they bring their original, richer perspective to bear in checking their program's behavior against their expectations. I will refer to these richer abstractions as "evaluation abstractions", in contrast to the formal "programming abstractions" embodied in the code. For example, suppose a programmer writes a program that attempts to navigate through a maze by following one wall from entrance to exit. Then, on running the program, the programmer sees the program follow an unconnected wall around in circles forever. In this example, the "programming abstractions" might be objects representing cells, walls, paths, or exits. Since there is no class or function called "go in circles forever", the programmer's awareness of this emergent behavior would be an "evaluation abstraction".
展开▼
