As many as you need, and no more.
There are just too many free variables for any pat answer to be meaningful. The number of acceptable modules depends on the absolute size of your code, the complexity of that code, and the amount of startup latency you can afford.
On the pro-module side, I happen to be a big fan of using tiny classes. These area basically data structures with a bit of test code thrown in, like arrays with boundary checking, strings which can never be zero length (useful for filenames), timestamps which can never be zero, and so forth. The whole module may contain a dozen lines of code or less, but the module justifies itself by making fifty to a hundred lines of higher level error-checking code unnecessary.
On the anti-module side, I've read far too many Perl scripts which could stand a good refactoring. The problem, of course, is that many people who use some module have never actually read the module itself. They've only read the documentation. Therefore, they know that the module contains function X, but they don't know how complicated that function is, or what other dependencies it creates.
I see that as a kind of cargo-cult programming.
Merlyn may not agree with me on this, but I think but I think my version is consistent with Feynman's original essay on cargo-cult science. Programmers who use a module because they know what it does, but don't know how it works, can end up getting unexpected results.. like ever-increasing chains of dependencies.
How much harm does that do? Again, there's no set answer. If you don't care whether your program takes an extra tenth of a second (or 700ms, assuming a 10ms average seek time and 70 extra modules) to open and load all the additional files, there's no problem. If you can't afford that extra startup latency (700ms won't cut it for Google or Slashdot), you'll probably be willing to dig through the code and factor out the parts you really do need. And I haven't heard any complaints about incompatible-version conflicts, but it's worth remembering that Perl isn't any more immune to those problems than Linux was.
FWIW, I'm also a big fan of inlining code rather than importing it. It's easy to reinvent the wheel if you have a perfectly good wheel to use as a design reference. You get the advantages of using mature code, you avoid the disadvantages of transitive dependencies, and you can learn a thing or two along the way.
In reply to How Many Modules Are 'Just Enough'?
by mstone
in thread How Many Modules Is Too Many?
by Belgarion
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |