1 |
On Fri, 13 Sep 2019 12:50:48 -0400 |
2 |
Michael Orlitzky <mjo@g.o> wrote: |
3 |
|
4 |
> On 9/12/19 1:45 PM, Alec Warner wrote: |
5 |
> > |
6 |
> > Er, I'm fairly sure computer *science* has not conclusively proven |
7 |
> > that dynamic binaries are somehow superior to static binaries. |
8 |
> > |
9 |
> |
10 |
> |
11 |
> If you statically link to a library, then none of its implementation |
12 |
> details are hidden from you -- you need to "reassemble" your program |
13 |
> whenever the library changes. |
14 |
> |
15 |
> If we jump way forward to 1979, the SICP[1] is basically a |
16 |
> thousand-page treatise on abstraction. But not only at one level of |
17 |
> computation: |
18 |
|
19 |
While I personally have opinions about static linking (I basically |
20 |
completely agree with you that it's a dumb idea). That said, this has |
21 |
nothing to do with this particular discussion, I suggest you take it up |
22 |
with the golang upstream. I don't think anyone here is arguing that |
23 |
static linking is a great idea and everyone should do it. |
24 |
|
25 |
We are arguing that the golang community believes strongly in static |
26 |
linking, and the entire ecosystem is designed around this idea, as such |
27 |
trying to bodge dynamic linking on to the existing ecosystem is |
28 |
probably more work than it is worth. In general, developers Gentoo |
29 |
tries to stay close to upstream as much as possible, as this reduces |
30 |
the maintenance burden. |
31 |
|
32 |
The entire point of this thread is to try to find a sane way to support |
33 |
the golang community's standards. I think the merits of static linking |
34 |
are out of scope here. |
35 |
|
36 |
> Well-designed computational systems, like well-designed automobiles |
37 |
> or nuclear reactors, are designed in a modular manner, so that the |
38 |
> parts can be constructed, replaced, and debugged separately. |
39 |
> |
40 |
> "Replaced" here is of course what I want to draw your attention to. |
41 |
> But also on the fact that abstraction and modularity don't just apply |
42 |
> at one level of software design and engineering -- it's a fractal. At |
43 |
> the lowest levels, we abstract machine code to assembler, assembler to |
44 |
> low-level languages, low-level languages to high-level languages, |
45 |
> high-level languages to functions and procedures, functions and |
46 |
> procedures to libraries, libraries to services, and services to |
47 |
> distributed APIs. The same principles that apply to a collection of |
48 |
> functions (a program) also apply to a collection of programs (an |
49 |
> operating system). The rule "don't copy and paste code" applies to |
50 |
> your linker just as much as it applies to the first program you wrote |
51 |
> in CS101, and for the same reasons. |
52 |
> |
53 |
> As you commented on IRC, the cost in terms of man-power is that |
54 |
> someone's workload jumps from O(n) to O(m*n), because you have to |
55 |
> duplicate everything you do for every statically-linked dependency. |
56 |
> And you can find as much theory as you like on software modularity in |
57 |
> papers from the 1970s and 1980s, but the benefits are not only |
58 |
> theoretical. There's a mountain of empirical data that supports the |
59 |
> theory. Some choice quotes [2][3]: |
60 |
> |
61 |
> Poorly placed dependencies, especially those that link otherwise |
62 |
> independent modules, may result in a cascade of unwanted and |
63 |
> hard-to- detect indirect interactions. Our results suggest that |
64 |
> purposeful actions to reduce such "rogue dependencies" can be |
65 |
> effective (the redesign of Mozilla reduced propagation cost by over |
66 |
> 80%). |
67 |
> |
68 |
> Our results confirm the existence of a relationship between |
69 |
> component modularity and design evolution that is both statistically |
70 |
> significant and large in magnitude... Tightly-coupled components |
71 |
> are... less adaptable via the processes of exclusion or |
72 |
> substitution; they are more likely to experience "surprise" |
73 |
> dependency additions unrelated to new functionality, implying that |
74 |
> they demand greater maintenance efforts; and they are harder to |
75 |
> augment, in that the mix of new components is more modular than the |
76 |
> 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 & |
80 |
> pastes code into his own program, he will eventually have to deal |
81 |
> with the mess. On the other hand, it he forces his program to be |
82 |
> statically linked, then it is the end user who is harmed by his |
83 |
> decision. |
84 |
> |
85 |
> In any case, the theory says that modularity is superior, and the |
86 |
> empirical data confirm it. The fact that you won't find a paper saying |
87 |
> "dynamic linking is better than static linking" is somewhat beside the |
88 |
> point, and only muddies the water. Linking is just one specific |
89 |
> instance of a problem that was solved 40 years ago. |
90 |
> |
91 |
> |
92 |
> [0] |
93 |
> https://www.win.tue.nl/~wstomv/edu/2ip30/references/criteria_for_modularization.pdf |
94 |
> |
95 |
> [1] https://web.mit.edu/alexmv/6.037/sicp.pdf |
96 |
> |
97 |
> [2] https://pubsonline.informs.org/doi/10.1287/mnsc.1060.0552 |
98 |
> |
99 |
> [3] http://www.hbs.edu/research/pdf/08-038.pdf |
100 |
> |