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.