There seems to be a fundamental dichotomy in computing between clarity and efficiency. From the programmer's point of view it is desirable to break a problem into sub problems and to tackle each of the sub problems independently. Once these have been solved the solutions are combined to provide a solution to the original problem. If the decomposition has been well chosen, the final solution will be a clear implementation of the algorithm, but because of intermediate values passing between the various modules, whether they are functions and procedures or separate processes connected by pipes, the solution is unlikely to be as efficient as possible. Conversely, if efficiency is considered paramount, many logically separate computations may need to be performed together. As a consequence, the algorithm will be reflected less directly in the program, and correctness may be hard to ascertain. Thus, in most programs we find a tradeoff between these conflicting requirements of clarity and efficiency.

An extreme form of modularisation is to write programs in an interpretive style, where flow of control is determined by stored data. Programs in this style are comparatively easy to prove correct and to modify when requirements change, but are well known to have extremely poor run-time behaviour–often an order of magnitude slower than their non-interpretive counterparts. Because of this, the interpretive style tends to be used infrequently and in non time-critical contexts. Instead, flow of control is determined deep within the program where a reasonable level of efficiency may be obtained.