4 ms·
I find it somewhat humorous that more than 25 years on, we are effectively reverting to static linking and bundling [1]. Way ... way back in the day, the argum
by hpcjoe 9y ago
I find it somewhat humorous that more than 25 years on, we are effectively reverting to static linking and bundling [1].
Way ... way back in the day, the argument was it would save memory, encourage reuse, etc. While some of this may have been true, it also gave rise to dynamic library hell. Reuse was overshadowed by incompatible versions, or API changes between versions that became the stuff of legends.
This would make a great study in how the ROI was completely overshadowed by risk considerations not considered at the outset.
Of course, saving memory was a huge issue in the days when 1GB RAM was considered gigantic. So maybe the cost was worth it.
[1] https://scalability.org/2017/03/what-is-old-is-new-again/ https://scalability.org/2017/03/what-is-old-is-new-again/
- Sean1708 9y ago> Way ... way back in the day, the argument was it would save memory ... it also gave rise to dynamic library hell. Could you expand a bit on how static linking would cause either of those things? It seems to me that they are both consequences of dynamic linking.
- kbenson 9y agoI think "the argument" being referred to was the push for dynamic linking, and the consequences in question are for dynamic linking. I think there was just a somewhat unclear implicit shift in the subject.
- raiph 9y ago> Reuse was overshadowed by incompatible versions, or API changes between versions that became the stuff of legends. The Perl community has spent a couple decades "enjoying" taking (or being forced to take) a long hard look at that. One result in P6 is :auth (authority), :api (api version) and :ver (package version) qualifiers, eg: use Some::Module:ver<1.2>:api<3.4>; with corresponding support throughout the language and packaging tools. Aiui this aspect of the language and tooling needs work but shows promise.