Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

Re: How Many Modules Are 'Just Enough'?

by BUU (Prior)
on May 30, 2004 at 10:46 UTC ( [id://357585]=note: print w/replies, xml ) Need Help??


in reply to How Many Modules Are 'Just Enough'?
in thread How Many Modules Is Too Many?

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?

Replies are listed 'Best First'.
Re: Re: How Many Modules Are 'Just Enough'?
by mstone (Deacon) on May 30, 2004 at 20:15 UTC

      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://357585]
help
Chatterbox?
and the web crawler heard nothing...

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

    No recent polls found