It's kind of funny how, rightfully, the author paints a picture where the "horrible, enlightened external dependency" itself is antimodular to the T. Given that

It's kind of funny how, rightfully, the author paints a picture where the "horrible, enlightened external dependency" itself is antimodular to the T. Given that all modules supposedly have stable interfaces, documentation, tests, reasonable size, yada yada then one might expect that each of their dependencies takes advantage of these properties to maintain light and wonderful themselves. Of course, this is a situation that's highly incompatible with C. Let's ditch that. In ML modules are king. You probably make hundreds in any non-trivial program and the compiler will beat your ass if you muck up their interfaces. Anywhere. Packages are just sets of 3 public modules wrapped up in twine and a README file (coincidentally this is where "ownership and lifecycle" are managed, but, sorry, I'm going to ignore those for a moment). This could be every bit as bad as I described before, but ML also realized that modules which just form a big dependency tree are actually quite annoying. The whole reason we define public APIs is so that there can be multiple satisficing inplementors, but this cannot be in 99% of module technologies today. So ML has functors (not Haskell functors, certainly certainly certainly not C++ functors) which are "parameterized modules that actually work". One could distribute their command line parsing module with a pluggable serialization and a pluggable help display. See MirageOS for a giant example of this kind of system working out. Does it really work? Probably not. It's not in most maintainers DNA to functor-ize everything. It's even a significant challenge to do so since you need to define sufficient external and internal public APIs and it's a significant community effort to standardize these sufficiently so that there is significant chance of re-use. But at least it's a way forward. Fight the heavy module trees. Let's use some higher order reusability.