Code Locality
Most coders agree that non trivial “[p]rograms […] obey the principle of locality“. (P.J. Denning and S.C. Schwartz) [Properties of the Working-Set Model] This principle is also known as the locality of reference and is divided in two types: temporal locality and spatial locality. However I postulate there is a third type: code locality. Ideally, source code consist of relative small blocks, each at their own level of abstraction, fully understandable in isolation. This makes sense if you realize “that our intellectual powers are rather geared to master static relations and that our powers to visualize processes evolving in time are relatively poorly developed.“ (E.W. Dijkstra) [Go To Statement Considered Harmful] This is why a goto needs a limited scope, a global variable needs to be constant, and multithreading needs queuing. Most agree that there exist “severe limitations on the amount of information that we are able to receive, process, and remember. By organizing the stimulus input simultaneously into several dimensions [abstraction layers] and successively into a sequence or chunks [code blocks], we manage to break […] this informational bottleneck.“ (G.A. Miller) [The Magical Number Seven] To prevent brain overload code locality is necessary. It will turn writing (or just understanding) code into a sequence of separate tasks where one task can be completed before the next is undertaken. “Completing the task means resolving the tension system […] If a task is not completed, a state of tension remains“. (Bluma Zeigernik) [On Finished and Unfinished Tasks] (Hint: click the photo.)
Thank you. I wish I could write an entry a day or even one good one a week. I prefer to write my own, not forward other good entries. Not that there is anything wrong with that blog model, it’s just that I would like to learn how to write well. Preferable in a modest amount of time.
I’ve struggled with this issue too.I haven’t come to any cotrcene conclusions either other than to emphasize that abstraction *costs*.And not only does it cost, but it usually costs *more* than we think it does because the person designing the abstraction is not the same person who has to invest the effort to learn how the abstraction works later on.I think this is one of the main reason why the fcberframeworks fail. When you try to build a framework in a vacuum, separate from a real application that uses the framework, you clearly don’t have a good grasp of the costs of the abstractions you’re creating.So I think whenever we create new abstractions we need to make sure we have very good reasons for doing so, and that we’re not unwittingly creating more trouble than we’re solving.