Gentoo Archives: gentoo-dev

From: Michael Orlitzky <mjo@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [PATCH 3/3] dev-vcs/hub: migrate to go-module.eclass
Date: Fri, 13 Sep 2019 16:50:57
Message-Id: 4050b216-b3fb-b444-4d88-7e7211804f4d@gentoo.org
In Reply to: Re: [gentoo-dev] [PATCH 3/3] dev-vcs/hub: migrate to go-module.eclass by Alec Warner
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

Replies