This article is very important. I encourage everyone to read it, as it raises a lot of good points.<p>In my opinion, the problem it describes come from the vagueness of the concept of elegance, and how counterintuitive it is. It doesn't even have to imply modules or anything like that. In the simplest form it boils down to:<p>Would you rather write:<p><pre><code> if (a) {
doSomething();
if (b) {
doSomethingElse();
}
}
</code></pre>
or<p><pre><code> if (a && b) {
doSomething();
doSomethingElse();
}
else if (a && !b) {
doSomething();
}
</code></pre>
Of course, there is no true answer to that question, and it always depends on the context. But many programmers will never ever consider option 2. And that is for two good reasons: 1, you make one more test, and 2 you duplicate the function call do doSomething(), so your program is larger. So mathematically speaking option 1 is more elegant, it's shorter, it's faster, it's lighter, what's not to like?<p>Well, multiply the ifs and the elses, and you will soon find out that option 2 is much more readable and changeable, which is the more elegant solution to anyone who's an engineer rather than a mathematician.<p>The tension it describes is that in every programmer is a mathematician and an engineer endlessly conflicting. This should be a good guidance for which style to use. Is this code a math code, or is it engineer's code. When you can answer that question, you can decide which style to write your code in.
The article makes some very important points and it's certainly worth a read for every programmer.<p>What the article misses to address explicitly however is that the whole redundancy vs. dependency conflict is caused by modularization. Without modules there would be no conflict.<p>So the real questions to answer here are: When do you need modules or do you need them at all? What should be modularized? And, most importantly, how to choose smart boundaries? Good answers to these questions will save a project from a world of pain down the road.<p>The classic OOP / software engineering education these days lacks critical debate about software modularization. Modularization is almost always presented as a good thing. What nobody tells you however is that in real world engineering, on real world teams, modularization can cause <i>a lot</i> of trouble if not done the right way.
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.<p>Of course, this is a situation that's highly incompatible with C. Let's ditch that.<p>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).<p>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.<p>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.<p>Does it really work?<p>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 <i>and</i> internal public APIs and it's a significant community effort to standardize these sufficiently so that there is significant chance of re-use.<p>But at least it's a way forward. Fight the heavy module trees. Let's use some higher order reusability.
I generally agree with this. However, sometimes using a module is not adding a dependency, it is making an already existing implicit dependency explicit.<p>E.g. we have client and server code. Serialization configuration between the two is implicitly dependent upon each other - if the client expects dates in a different format than the server, things don't work. To make that implicit dependency explicit, we use a module, which also has the affect of making sure the two don't get out of synch.
A very good article that aptly shows (some of) the hard & sticky questions we are confronted with all the time. How you answer these questions will determine the quality & stability of your code to a large extent.<p>I agree with the OP that commonly, “<i>dependencies are worse</i>”. Redundancy will increase the quantity of your code, but dependencies increase its complexity. And quantity is always conquered easier than complexity.
This depends greatly on your platform. Java projects accept dependencies much easier than C++ ones because in Java it's much harder to cause trouble and also coding styles aren't radically different for different dependencies.<p>Perl&Ruby are even more eager, which should be strange since they're actually less safe.
Excellent article. Just one quibble: he claims a module shouldn't be over 30k lines. Counterexamples: Linux, Postgres, Boost, LLVM, V8, all in the million line range. To be sure, each of these has an internal module structure, but that's irrelevant from the perspective of someone deciding whether to incur a dependency on one of them - the answer to which may very well be yes because they do enough to make it worthwhile.<p>If anything, larger modules like the ones I listed are more likely to be worth depending on because they do more. It's no coincidence that the author chooses command line parsing as a negative example - something trivial enough that the overhead of tracking a dependency may well outweigh the effort of implementing it yourself.