1 |
On 9/12/19 1:45 PM, Alec Warner wrote: |
2 |
> |
3 |
> Er, I'm fairly sure computer *science* has not conclusively proven that |
4 |
> dynamic binaries are somehow superior to static binaries. |
5 |
> |
6 |
|
7 |
Please don't make me work this hard ever again. |
8 |
|
9 |
The principal of modularity in software design goes back to at least |
10 |
1970. In Parnas's famous 1971 paper[0], he cites "Designing Systems |
11 |
Programs" by Gauthier and Pont from 1970, and suggests that the idea |
12 |
goes back even further, to at least 1967 (Balzer & Mealy). On the very |
13 |
first page of Parnas' paper, he says |
14 |
|
15 |
The major advancement in the area of modular programming has been the |
16 |
development of coding techniques and assemblers which |
17 |
|
18 |
(1) allow one module to be written with little knowledge of the code |
19 |
in another module, and |
20 |
|
21 |
(2) allow modules to be reassembled and replaced without reassembly |
22 |
of the whole system. |
23 |
|
24 |
The second item has a clear interpretation in terms of static/dynamic |
25 |
linking. Parnas concludes that |
26 |
|
27 |
...one begins with a list of difficult design decisions or design |
28 |
decisions which are likely to change. Each module is then designed to |
29 |
hide such a decision from the others. |
30 |
|
31 |
If you statically link to a library, then none of its implementation |
32 |
details are hidden from you -- you need to "reassemble" your program |
33 |
whenever the library changes. |
34 |
|
35 |
If we jump way forward to 1979, the SICP[1] is basically a thousand-page |
36 |
treatise on abstraction. But not only at one level of computation: |
37 |
|
38 |
Well-designed computational systems, like well-designed automobiles or |
39 |
nuclear reactors, are designed in a modular manner, so that the parts |
40 |
can be constructed, replaced, and debugged separately. |
41 |
|
42 |
"Replaced" here is of course what I want to draw your attention to. But |
43 |
also on the fact that abstraction and modularity don't just apply at one |
44 |
level of software design and engineering -- it's a fractal. At the |
45 |
lowest levels, we abstract machine code to assembler, assembler to |
46 |
low-level languages, low-level languages to high-level languages, |
47 |
high-level languages to functions and procedures, functions and |
48 |
procedures to libraries, libraries to services, and services to |
49 |
distributed APIs. The same principles that apply to a collection of |
50 |
functions (a program) also apply to a collection of programs (an |
51 |
operating system). The rule "don't copy and paste code" applies to your |
52 |
linker just as much as it applies to the first program you wrote in |
53 |
CS101, and for the same reasons. |
54 |
|
55 |
As you commented on IRC, the cost in terms of man-power is that |
56 |
someone's workload jumps from O(n) to O(m*n), because you have to |
57 |
duplicate everything you do for every statically-linked dependency. And |
58 |
you can find as much theory as you like on software modularity in papers |
59 |
from the 1970s and 1980s, but the benefits are not only theoretical. |
60 |
There's a mountain of empirical data that supports the theory. Some |
61 |
choice quotes [2][3]: |
62 |
|
63 |
Poorly placed dependencies, especially those that link otherwise |
64 |
independent modules, may result in a cascade of unwanted and hard-to- |
65 |
detect indirect interactions. Our results suggest that purposeful |
66 |
actions to reduce such "rogue dependencies" can be effective (the |
67 |
redesign of Mozilla reduced propagation cost by over 80%). |
68 |
|
69 |
Our results confirm the existence of a relationship between component |
70 |
modularity and design evolution that is both statistically significant |
71 |
and large in magnitude... Tightly-coupled components are... less |
72 |
adaptable via the processes of exclusion or substitution; they are |
73 |
more likely to experience "surprise" dependency additions unrelated |
74 |
to new functionality, implying that they demand greater maintenance |
75 |
efforts; and they are harder to augment, in that the mix of new |
76 |
components is more modular than the legacy design. |
77 |
|
78 |
The only difference between static linking and copy/pasting chunks of |
79 |
code around is in who pays the price. If the programmer copies & pastes |
80 |
code into his own program, he will eventually have to deal with the |
81 |
mess. On the other hand, it he forces his program to be statically |
82 |
linked, then it is the end user who is harmed by his decision. |
83 |
|
84 |
In any case, the theory says that modularity is superior, and the |
85 |
empirical data confirm it. The fact that you won't find a paper saying |
86 |
"dynamic linking is better than static linking" is somewhat beside the |
87 |
point, and only muddies the water. Linking is just one specific instance |
88 |
of a problem that was solved 40 years ago. |
89 |
|
90 |
|
91 |
[0] |
92 |
https://www.win.tue.nl/~wstomv/edu/2ip30/references/criteria_for_modularization.pdf |
93 |
|
94 |
[1] https://web.mit.edu/alexmv/6.037/sicp.pdf |
95 |
|
96 |
[2] https://pubsonline.informs.org/doi/10.1287/mnsc.1060.0552 |
97 |
|
98 |
[3] http://www.hbs.edu/research/pdf/08-038.pdf |