# Static program and dynamic process > The distinction between static program and dynamic process The distinction between static program and dynamic process ## [E. Dijkstra](https://wiki.g15e.com/pages/Edsger%20Dijkstra.txt) In the GOTO essay (1968), Dijkstra says this: > We should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap beween **the static program and the dynamic process**, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible. --[Go to statement considered harmful](https://wiki.g15e.com/pages/Go%20to%20statement%20considered%20harmful.txt) ## Going a bit further back, a similar expression appears in the report , written in <1947> by and . > C scans the sequence of codes, and effects the instructions, which they contain, one by one. If this were just a linear scanning of the coded sequence, the latter remaining throughout the procedure unchanged in form, then matters would be quite simple…. This, however, is not the case. We are convinced, both on general grounds and from our actual experience with the coding of specific numerical problems, that the main difficulty lies just at this point…. C will, in general, not scan the coded sequence of instructions linearly. It may jump occasionally forward or backward, omitting (for the time being, but probably not permanently) some parts of the sequence, and going repeatedly through others. It may modify some parts of the sequence while obeying the instructions in another part of the sequence…. Thus **the relation of the coded instruction sequence to the mathematically conceived procedure of (numerical) solution is not a statical one, that of a translation, but highly dynamical….** These complications are, furthermore, not hypothetical or exceptional. It does not require a deep analysis of any inductive or iterative mathematical process to see that they are indeed the norm. In the passage above, "C" refers to the program counter, or instruction pointer, or the line currently being executed. "Selectron memory" refers to a memory device used in the past; in today's terms it would be . It is also notable that the quotation above assumes a situation in which not only data but code as well changes dynamically during execution. These days, unless it is a very exceptional situation (for example, trying intentionally to make the behavior of code hard to understand, or doing hacking such as buffer overflows), code is either not modified during execution or such modification is supported only in a very controlled way. Some languages (mainly [functional languages](https://wiki.g15e.com/pages/Functional%20programming.txt)) even constrain the values of variables to be immutable. ## AOP Meanwhile, according to , the development of proceeded in the direction of weakening the correspondence between static program and dynamic process: > The earliest computer machine-language programs had **a strict correspondence between the program text and the execution pattern**. Generally, each programming language statement was both unitary and local - unitary in that it ended up having effect in precisely one place in the elaborated program, and local in that it was almost always proximate to the statements executing around it > > The history (of this part) of programming languages has been about moving away from purely local and unitary languages and toward mechanisms that let the programmer separate concepts into pragmatic assemblages or mudles, instead of being tied to saying things just where they happen. The first exceptions to locality were subprograms (i.e., procedures, subroutines, functions). Subprograms were a great invention, enabling abstracting out some behavior to someplace else, They have many virtues for separating concerns. … > > (and related mechanisms like ) in was another important introduction of non-locality. Executing inherited behavior is non-local. --p22, ## Resolving the conflict between the two views The two views above seem to conflict, but they do not. The reason it is said to be good to reduce the gap between static program and dynamic process is that, within a single module, doing so lowers the programmer's . The reason it is good for the level of abstraction of the various statements contained in one function to be kept consistent is also that this reduces the need to stop reading one function midway and move around here and there in order to read other functions. The reason it is said to be good to weaken the correspondence between static program and dynamic process is that by isolating modules that deal with different concerns, one can consequently reduce the gap between static program and dynamic process within a single module. - 's prevents the concerns of lower modules from becoming entangled within the concerns of higher modules through [dependency inversion](https://wiki.g15e.com/en/pages/Dependency%20inversion.txt). - In [AOP](https://wiki.g15e.com/pages/Aspect-oriented%20programming.txt), projecting dynamically woven () [multidimensional concerns](https://wiki.g15e.com/pages/Multidimensional%20separation%20of%20concerns.txt) into a static two-dimensional space organized around one concern inevitably scatters the others ([the tyranny of the dominant decomposition](https://wiki.g15e.com/pages/Tyranny%20of%20the%20dominant%20decomposition.txt)). AOP introduces a modularization unit called an to address this problem. - The subroutine in is the same. If you understand it as saying that what matters is reducing the gap between static program and dynamic process within a module that deals with one concern, and that in order to achieve this it must also be possible, when necessary, to separate the correspondence between the two appropriately, then there is no conflict between the two perspectives.