Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

How Many Modules Are 'Just Enough'?

by mstone (Deacon)
on May 30, 2004 at 08:05 UTC ( [id://357570]=note: print w/replies, xml ) Need Help??


in reply to How Many Modules Is Too Many?

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.

Replies are listed 'Best First'.
Re: How Many Modules Are 'Just Enough'?
by BUU (Prior) on May 30, 2004 at 10:46 UTC
    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.
    While you have a point about "not really understanding the module you're using", the problem is that: Where do you stop needing to understand what you're doing?

    Do you need to understand everything perl is doing at the C level? Everything C is doing at the ASM level? Everything ASM is doing at the uh, binary level (whatever the level below that is considered. Machine code?). Where do you stop needing to understand and just use the functionality?

        Where do you stop needing to understand what you're doing?

      Once again, there's no pat answer. It depends on what you do with the code.

      For a script you don't plan to use often, or for anything critical, you don't have to dig very far. Your code can be as sloppy(1) as you want it to be, because you're willing to accept the consequences, and you're not foisting them off on anyone else.

      (1) - I don't mean to suggest that 'sloppy' is inherently bad. All code exists on a scale with 'sloppy' at one end and 'obsessive' at the other. A script that's 90% sloppy is still 10% obsessive, and one that's 90% obsessive is still 10% sloppy. Part of the programmer's job is deciding where on that scale each project should fall.

      If you intend to use your code a lot, or to publish it for others to use, I personally think it's polite to shoot for the 'obsessive' end of the scale. At very least, you should work to avoid problems that are known and understood.

      Implicit dependencies are a known, well-understood problem. Windows users have lived in 'DLL Hell' for years, and Linux developers have reinvented that same, butt-ugly wheel for themselves. Everyone wants to use libraries, but nobody can agree on which version of any given library to use, and the installers will happily replace some item 5 layers deep with another, possibly incompatible version.

      Anyone who knows Open Source knows that large-scale coordination is one of the weak points of OSS development. Anyone who knows game theory knows that environments like that are fertile soil for yet another version of DLL Hell. The way to avoid creating a Perl version of DLL Hell is for each developer to be properly Lazy, and eliminate as many dependency problems as possible themselves, so people down the line won't have to.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://357570]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others chilling in the Monastery: (5)
As of 2024-03-19 10:03 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found