Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Re: Top Seven (Bad) Reasons Not To Use Modules

by Erez (Priest)
on Mar 15, 2009 at 11:21 UTC ( [id://750712]=note: print w/replies, xml ) Need Help??


in reply to Top Seven (Bad) Reasons Not To Use Modules

WRT #4, I'm of two minds on the subject. On one hand, I tend to scoff at the "no installation needed" at a day and age where users have machines infested with Java and Flash installation (often 2 or 3 of them) as well as other runtime environments. Maintaining a solid CPAN installation is usually easy and simple, and getting easier and simpler each day.

OTOH, I encountered several instances where what was supposed to be a simple module turned out to be a full blown framework with Moose on top (hello, Jifty). This immediately get a "to be removed/replaced" tag.

In regards to the entire post, as much as I'm a supporter of Best Practices Preaching, it tends to be considered as gospel, to be followed blindly, rather than "general rules that you may benefit from following". There are cases where all the above reasons are not valid, and, as mentioned above, cases where those should not be followed at all. There is no One True Rule, despite the many claims here, and elsewhere.

"A core tenant of the greater Perl philosophy is to trust that the developer knows enough to solve the problem" - Jay Shirley, A case for Catalyst.

Replies are listed 'Best First'.
Re^2: Top Seven (Bad) Reasons Not To Use Modules
by JavaFan (Canon) on Mar 15, 2009 at 12:28 UTC
    I tend to scoff at the "no installation needed" at a day and age where users have machines infested with Java and Flash installation (often 2 or 3 of them) as well as other runtime environments.
    But there's a large difference between a user machine (which, nowadays, typically gets used by a single person, can be easily replaced, and if down, only affects one person) and a server that is important or even critical for the operation of a business.

    Having said that, I've worked on servers that have multiple Java installations as well - and, IMO, that was good. An application that needs Java, and comes with everything needed to run Java is so much easier to install than one that doesn't. If the app comes with Java, it will always have the right version (and if it doesn't, I can blame the vendor of the app) and will not conflict with other apps needing Java. And, IMO, that's the way to deliver (large) Perl applications as well. Include everything. All modules you need. Consider including perl itself as well (because even if your target OS comes with perl, it may not be the right version or it may be compiled with the wrong options).

    There is no One True Rule, despite the many claims here, and elsewhere.
    That, I fully agree with.
Re^2: Top Seven (Bad) Reasons Not To Use Modules
by bellaire (Hermit) on Mar 15, 2009 at 16:34 UTC
    I agree that there's the danger of advice being taken as gospel, as you put it. FWIW, I don't ask that anyone substitute my judgment for theirs, and I don't by any means think there is One True Rule on how to go about things. The only One True Rule is: think about what you are doing and use your best judgment.

    I simply felt that if I'm going to take a position in the meditation, it should be consistent. I wanted to offer food for thought, and so I presented my reasoning as directly as possible. As I've mentioned elsewhere, I've mainly been in situations where these arguments make sense: my systems don't get pushed to more than a handful of servers and accounts, and my organization's policies give me wide latitude to choose what software I need to accomplish the task at hand.

    Someone else would be much better qualified to write the contrary meditation on Top N (Good) Reasons Not To Use Modules. Maybe JavaFan? :)
      I think that in general good meditations show both sides of the arguments. The way you wrote your meditation was to present the counter-argument to use a module, and then to be very dismissive about it, in a style of writing that suggests only inferior developers could have considered such arguments.

      That's a way of writing that suggests to me you yourself didn't think the arguments over. Articles that picture the world using more shades of gray than black and white are far more useful - and carry much more weight in my book.

        Fair enough. That wasn't my intent, so I'm sorry it was taken that way.

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others wandering the Monastery: (4)
As of 2024-03-28 16:59 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found