http://www.perlmonks.org?node_id=313987

I just checked out this node -- it happened to be on top at the Monastery Gates when I logged in. There were many responses that tried to answer the question, and lots of back-and-forth between the "seeker of wisdom" and the various helpful monks.

I was compelled to post a reply (which will fall below most monks' radar -- a "Re^5", responding to the seeker at a deeply embedded point in the dialog), where I basically said: Why would anyone want to "solve" this particular problem?

The OP question was: how do you set up a script to automatically "use" all the modules in a given directory, without having to name each module explicitly in the script?

At the time that I posted my reply there, lots of people had pointed to the "require" pragma rather than "use" -- which is syntacticaly correct (though it's not clear that the OP was able to make it work as intended). But no one besides me had commented or inquired about whether getting this to work would be advantageous, prudent or even sensible.

So, my first "koan" relates to that OP specifically: Is there a situation where you would want a perl script to implicitly/automatically load all modules in a given directory? Imagine that part of the motivation is that, when you add more modules to that directory, you don't have to add more "use ModuleN" statements to the script that is using all those modules. Am I missing something by thinking that this is not never a good idea?

The second is more of a leading question that folks here have probably seen before: When someone asks how to achieve a particular result in order to gain some advantage in their work, and this is likely or certain to create some larger problem, do you just answer the question, or do you point out the larger problem?

Replies are listed 'Best First'.
Re: Being helpful to a fault?
by BUU (Prior) on Dec 11, 2003 at 06:43 UTC
    This raises a personal peeve of mine, namely people trying to "answer the larger problem". The idea behind that is noble of course, but nine times out of ten the person asking the question knows more about the problem and has probably considered all the alternatives and so on. When you attempt to "solve the larger problem" you do so with out all of the knowledge you need to adequately do this as you are forced to make assumptions based on the original question. The end result of this is that you don't answer the question and you sound arrogant/condescending.

    Obligatory examples:
    Ex 1.
    Seeker: Hey, I'm trying to write a bubble sort routine, sorting against this array. This is my attempt code. However the last element doesn't get sorted properly, can you see what I'm doing wrong?

    Response: Omg bubble sorts are really bad and evil and you should never use them. Write a quick sort now.

    Ex 2.
    Seeker: Hey, I'm trying to write the fastest sort routine for this data and I seem to remember that a bubble sort is the fastest one, but my implementation, here, doesn't seem to sort the last element properly, anyone see whats wrong?

    Response: You are doing X wrong, but a bubble sort is not in fact the fastest, you would be much better served by looking at a quicksort.

    Obviously these examples are contrived, but I hope they illustrate my point.
    In example 1, the response is totally useless as he doesn't answer the stated question. He assumes the seeker is attempting to do something else and then tries to answer based on that assumption. I'm sure you are all aware of what assuming does.. =]. Granted its possible that the seeker was attempting to write the fastest sort possible and was misinformed that a bubble sort was fastest. But he never, ever states that. He could be writing a bubble sort just to see how it works, or for homework or any number of reasons, none of which the responder knows. It's one thing to ask "are you sure you don't want a faster algorithm?" but just assuming he does and then going off on that tangent, I at least, find it minorly annoying to greatly irritating, depending on the tone of the response.

    Example 2 gives much more information and implies a larger question then just "what is wrong with this algorithm", the question being "whats the fastest way to do this". The response answers both questions, thus being a good response.

    Update: Dunno where that "nine times out of ten" thing came from.. I think I just meant "most of the time".

    Update, part deux: I think my main point was not that questioning basic assumptions is bad, but that most people tend to do it in a way that is insulting to the original poster.
      As someone who often tries to "answer the bigger question", let me respond.

      Perhaps in 9 out of 10 cases, the person really has thought things through. (I don't believe that, but I won't argue the made-up statistic.)

      I don't have to because in more than 9 out of 10 cases I don't respond that way. In fact I only choose to respond that way when I see what I take to be cues that indicate that in this case the person hasn't thought things through. And I've hit the mark often enough that I am convinced that trying to answer the larger problem is worthwhile, despite the fact that I miss the boat sometimes.

      (An incidental side point. In your made-up example, the chorus of responses would be to just use Perl's built-in sort.)

        49% of all statistics are just made up on the spot. 87% of people know that.

        ------------
        :Wq
        Not an editor command: Wq
        An incidental side point. In your made-up example, the chorus of responses would be to just use Perl's built-in sort.
        Which, on modern Perls, isn't a quicksort by default.

        Abigail

      I think it's usually obvious when someone hasn't thought things through. In your example, if the poster says "I'm writing up this bubble sort just for learning", then its clear that its not going to be used in practice and we can all safely answer the question as stated without the ingrained engineer's response of saying "That shouldn't be that way!"

      However, 9 times out of 10 (I got that statistic from the same place you did), someone implementing a bubble sort is mearly naive.

      A better example, which actually comes up a lot, is someone with a buggy CGI parser. The automatic (and correct, IMNHO) response is to point them to CGI.pm.

      (Side point: I must wonder how many people using hand-coded CGI parsers actually understand the code they put in. Even buggy ones are a rather complex series of regular expressions and relatively deep Perl-isms. I certainly didn't understand them when I was doing it.)

      ----
      I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
      -- Schemer

      : () { :|:& };:

      Note: All code is untested, unless otherwise stated

Re: Being helpful to a fault?
by Aristotle (Chancellor) on Dec 11, 2003 at 12:18 UTC
    1. Certainly. A plugin system for a program comes to mind immediately, where plugins are modules with a specific interface and are added simply by dropping them in a directory.

      "Why would anyone want to do X?" is never a good reason to advise against it. If you can say "almost all the people who do X suffer Y" then you do have a case. I am reminded of my recent rereading of Mark-Jason Dominus' Critique of the Perl 6 RFC Process; specifically, this passage:

      People would frequently send me mail asking me to add a certain feature, such as timed expiration of cached data. I would reply that I didn't want to do that, because it would slow down the module for everyone, and it would not help the next time I got a similar but slightly different request, such as a request for data that expires when it has been used a fixed number of times. The response was invariably along the lines of "But what would anyone want to do that for?" And then the following week I would get mail from someone else asking for expiration of data after it had been used a fixed number of times, and I would say that I didn't want to put this in because it wouldn't help people with the problem of timed expiration and the response would be exactly the same.
    2. Which way I'll answer depends on how much information the poster gives. If I can clearly see that he's getting himself into trouble, I'll point out that it shouldn't be done this way first and explain why, and then add the solution requested merely as a point of interest, hoping that the poster will learn how to do what he wanted while steering clear of that solution for the case he asked about. If there isn't that much information, or if it isn't clearly a bad idea but just could be done better, then I'll answer the question and add a few words on the advantages of doing it another way. If I can only suspect that a certain bad idea is the motivation, then along with the answer to the question I might add something along the lines of "you're not trying to do X, are you? if so, then you shouldn't, do Y instead" or ".. if so, then we can probably point out a better way if you give us more information".

    Makeshifts last the longest.

Re: Being helpful to a fault?
by edan (Curate) on Dec 11, 2003 at 07:33 UTC

    When you answer someone's question, you are trying to help them. If you feel that the best help you can offer is to question the original assumptions of the question, then go right ahead. Very often that can be a big help, because people sometimes get caught up in their original assumptions when they are trying to solve a problem, and someone else can just say 'Hey, why don't we find a different way to solve the original problem, rather than finding a way to do it the way you are trying to solve it, becauase there's a better way', and the questioner will 'see the light'.

    But I do think it's important to keep in mind that sometimes people actually do have good reasons for doing something a certain way, so it's always nice to suggest that there might be an alternative way of looking at the problem in a way that 'gives some credit' to the person asking the question.

    I think my point is this: the point of this forum is for people to help each other and learn from each other. Different people have different ways of doing this. If your helpful input is to suggest finding a different way to approach the problem, great! If the person doesn't benefit from your help, because s/he knows the whole picture and can't do it any other way, so there's no great loss, right? The best of both worlds might be 'You can solve your problem X as stated by doing Y. But, I question the need to do X in the first place - I think it's bad because of Z. Perhaps if you tell us the higher-level problem you are trying to solve, we can help you find a better approach.'

    --
    3dan

Re: Being helpful to a fault?
by pg (Canon) on Dec 11, 2003 at 06:51 UTC

    I have to agree with you. A bad idea is still a bad idea even if you carry it out smartly.

    I tell you what I do:

    In Java, regardless whether I need all of the classes in a particular package, I can easily import all of them by doing something like:

    import java.util.*;

    But I never did that, instead I always specify each class I need:

    import java.util.Vector; import java.util.Hashtable;

    Why? Because I know what I am doing, and want to hold it tightly.

      While everyone's talking about "9 times out of 10," my first guess at reading that other node was that the poster was familiar with the Java idiom, and just wanted to do the same thing in Perl. Of course, a six-line bit of cargo-cult chicanery isn't a useful idiom, but the question was interesting anyway. The "bigger question" here is that idioms are just that: they make sense in one language, but don't translate as well. "You're pulling my leg" means nothing without cultural context. import java.util.*; is similarly bizarre to people wearing Perl-colored glasses.

      --
      [ e d @ h a l l e y . c c ]

Re: Being helpful to a fault?
by rchiav (Deacon) on Dec 11, 2003 at 13:10 UTC
    I just read trough all the replies to see if anyone else's first thought when reading the node you're referring to was the same as my first though. Aristotle and I seem to think alike. Auto loading modules for a plugin system would be pretty valid.

    And it also bothers me that people try to "answer the bigger question" without answering the question that was actually asked. It's pretty egotistical to think that what the author of a question is trying to do is only a good idea if you can make sense of it.

    You didn't tell the author that you were curious what this would be used for or that you were having a hard time understanding it's application. You said that it made little or no sense and that you would loose your sanity if you had to maintain his script, implying he's a bad programmer because of your lack of open mindedness.

    What that really says to me is that anything that you can't grasp a use for MUST be useless. To me that's pretty closed minded and lacks creativity.

      Auto loading modules for a plugin system would be pretty valid.

      I must beg to differ. Or at least, I can't think of a reason :-).

      • Listing modules in a location, for a user to choose from, would be pretty valid. I suppose.
        But what if a plugin didn't appear as MyCompany::Plugins::PluginName? What if it was ThirdParty::CompanyPlugins::PluginName?
      • Auto-loading modules when required would be pretty valid.
        But that's just

        eval "use $module()" or die "Could not load plugin $module, error: $!";

      • Auto-loading modules listed in a config file would be pretty valid.
        Or just require() a file which use-s the ones you want. (Hey, perl has a syntax, why invent another?)

      But why would you want to auto-load modules in a location? If you want to temporarily stop using the module, you'd have to uninstall it.

        You have a perl app named someapp.pl. With the app is a spec on how to create plugins for the app. The plugins go into /etc/someapp/. Sharpdevelop does this very thing (but it's not Perl). There's a spec on how to create a plugin and it will load all plugins in the plugin path.

        I'm not saying that the person who asked the question was even intending this, but how is it your or my place to tell someone their wrong without even knowing what they're doing? If something seems suspicious, tell them you're curious as to why. But again, just because you can't see a valid reason doesn't mean that there isn't a valid reason.

Re: Being helpful to a fault?
by Arbogast (Monk) on Dec 11, 2003 at 06:10 UTC
    Your answer was the best. The question was interesting as a thought excercise only, and was in severe violation of the KISS principle in the real world as best I could tell.
      Maybe you know all the modules in a particular plugin directory is to be made available, and presented as choices? -s

      Play that funky music white boy..
Re: Being helpful to a fault?
by BrowserUk (Patriarch) on Dec 11, 2003 at 11:50 UTC

    Koan 1: Yes there are.

    Koan 2: Answer the question as accurately as possible. Finish with a simple statement that there is probably a better way.


    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "Think for yourself!" - Abigail
    Hooray!

Re: Being helpful to a fault?
by hanenkamp (Pilgrim) on Dec 11, 2003 at 14:04 UTC

    I too gave an answer in to this particular post. I thought about the fact that it was likely a bad idea, but I thought of the plugin system that Aristotle pointed out and so didn't consider putting in a warning--I think that perhaps I should have, but nothing as severe as saying, "I'm sorry, but something about this train of thought makes little or no sense."

    My opinion is that we can have it both ways. I think it's pretty unwise to assume that we have the answer for someone else's situation when we only have their one question. I also think that part of Perl's mystique is that it's alright to sometimes solve a problem the "wrong way" for various reasons. At the same time, I think we should be careful to point out when a certain action might not be a good idea.

    There's no reason to be presumptuous and state, "Don't do that!" All we have to say is, "In general, that's probably not a good idea because of X." Then, they can make the judgement call, "Is my situation such that I'm willing to face X in return for some benefit Y."

    It bothers me a little when Perl hackers persecute each other for doing things the wrong way (TMTOWTDI) when much of the rest of the information technology world persecutes us for using the wrong language. Thus, make your recommendation to help someone who might not have thought of a given problem, but remember that there are no hard-fast rules in Perl, so any guideline may be wrong for their situation.

      I also think that part of Perl's mystique is that it's alright to sometimes solve a problem the "wrong way" for various reasons.
      That's not specific to Perl - it applies everywhere. It's called Worse is Better and means that there's no one single metric by which to measure the quality of a work. There are many, and what's better by one or several of them is not necessarily better by one or more others. There's usually one commonly accepted way that will get you a decent or good result in the majority of cases, but that isn't necessarily appropriate for all case. Weighing choices well here requires an observative and experienced programmer. To quote The Tao of Programming:
      There once was a master programmer who wrote unstructured programs. A novice programmer, seeking to imitate him, also began to write unstructured programs. When the novice asked the master to evaluate his progress, the master criticised him for writing unstructured programs, saying: "What is appropriate for the master is not appropriate for the novice. You must understand Tao before transcending structure."
      In other words, you have to understand the spirit and the reasoning of rules in order to be able to appropriately judge when to break them.

      Makeshifts last the longest.

Re: Being helpful to a fault?
by delirium (Chaplain) on Dec 11, 2003 at 14:15 UTC
    On a similar note, I've noticed many occasions where posters (Anonymous Monks usually) ask ambigious questions, and an eager set of responders try to permute every possible thing the original poster may have meant. e.g.,

    Q: How to I load files into teh PERL?

    A: Assuming you mean how to read a file into an array, you would say open FH, 'file'; my @array=<FH>;. On the other hand, you might mean how to download a file from an FTP server. You could use the handy Net::FTP module....

    ...and so forth. In my opinion, unclear questions need to be clarified a little first. This lets the poster know that someone is interested in working with them on their problem, and in the (many) cases where the poster never returns, the forum doesn't get clogged with discussion aimed at helping someone who is long gone.

    For those questions that are clear, but you think the poster is heading in the wrong direction, speak up! The answer to his/her question is probably out there in a tutorial or a Perl book, and would be found eventually. But he/she came to us instead. The benefit of talking to people is that they can see when it's appropriate to meaningfully jump out of context.

      But no one besides me had commented or inquired about whether getting this to work would be advantageous, prudent or even sensible.

      I don't think there is a fault. As previously mentioned, perhaps you have not considered all the possible ways this "auto-use" could be useful. Many applications, such as Adobe PhotoShop, have plugins folders. You can drop libraries into these folders and they automagically become loaded by the application. This is great as third party users can install plugins very easily.

      Is there a manageable security risk, yes (use access permissions!)...but is it cool? Definitely yes. It has applications. So the approach can't be completely wrong.

      Anyhow, some approaches (such as using telnet when SSHD is available) are right to question...some are in a gray area, and being pedantic can annoy some folks. I'd prefer to have these folks learn by doing rather than saying no outright. They may know more than the responder in many cases. Conclusions -- Raise potential issues, but avoid calling someone wrong or saying the approach is wrong.

•Re: Being helpful to a fault?
by merlyn (Sage) on Dec 11, 2003 at 13:52 UTC
Re: Being helpful to a fault?
by Zero_Flop (Pilgrim) on Dec 12, 2003 at 01:24 UTC
    Just to respond on your first question. Yes, it is useful to load all of the modules in a directory. As Aristotle mentioned it is nice if you are working on a plugin system. I have seen this used particularly in IRC bots.

    You do NOT do require XML::*, but rather you require all of the files in a program specific directory.

    Normally once you require all of the modules, you run a setup routine in each file that generates hooks. Then in IRC as an example, when an event occurs all of the associated hooks in your hash are executed.

    ex. You ask the bot what time it is. Clock module gets the local time of the requestor. if smart *ss module loaded, generate smart *ss responce if normal module loaded, generate normal responce.

    Another nice benifit is you can dynamicly load and unload the modules without having to shutdown the bot. So you can administer the bot remotly.

    Zero
      Thanks. My first question was in fact the one that mattered more to me. (I just couldn't seem to stop myself from going on to the second.)

      I also appreciated the comments by rchiavo and hardburn, who hit the crux of the matter pretty well: I confess to having been clueless about the mechanics of plugins, or how they would benefit from a design that says "load whatever exists in this path", and I should have just started with curiousity instead of criticism.

      But your reply was the first one to give some clues about plugins (which are still somewhat mysterious to me), and I'm grateful for that.

        Graff-

        Just for your information and so you can get a better feel to what this can do for you. Check out perlbot.org

        From the site:
        "Perlbot is a totally modular bot. All functionality is provided by Plugins which use a standard, simple API."

        Sorry I could not think of the name when I wrote the first note at work.

Re: Being helpful to a fault?
by Steve_p (Priest) on Dec 11, 2003 at 13:08 UTC

    Regarding your first question, I don't think there is a situation where you would want to, by default, load in every module in a directory. Could you imagine seeing

    use XML::*;

    in someone's code? Not cool.

    I can see the motivation of the original question and how it could occur and why someone might think that it is what they want, and I'm guessing that its related to Object Oriented Perl. Let's say you have a perl class Foo, with subclasses Foo::A, Foo::B, and Foo::C. Now, if you have a script that could have any of those classes returned from a function call you would need to include all those packages. Now, if the function called from your script is changed to also return Foo::D, your script will likely be broken.

    On your second question, I typically point to the larger problem if I can see one, and provide some options to solving the larger problem. I won't, however, go into a typical question assuming there is a major flaw in their design. In the case with this question, I'm assuming the layout of their modules, while working fine for their initial design, development, and testing, are turning into a pain when modified. Now, a change in file A is forcing changes in file B. If that is truly the deeper problem, rather than trying to work around use, they should look to placing the classes in question into a single file.

      I don't think there is a situation where you would want to, by default, load in every module in a directory.

      Frankly, just because you don't see a reason for it, someone else may have a perfectly valid reason. In fact, I there is at least one good reason to do this: testing that all modules in a directory will load.

      Also, as another poster pointed out, this is supported by default in other languages, like Java:

      import java.io.*;

      Which is a case of Java supporting more laziness than Perl (a case which is quite rare).

      ----
      I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
      -- Schemer

      : () { :|:& };:

      Note: All code is untested, unless otherwise stated

Re: Being helpful to a fault?
by jdtoronto (Prior) on Dec 12, 2003 at 18:39 UTC
    Great meditation graff. The OMG why would anyone want to do that response is so common that I tune out when I see it now, not just here, but everywhere. The bigger question needs to be asked, and answered. But we also need to make sure it is done in such a way as to educate the OP. Difficult? Yeah!

    I see some major problems in any such forum as this:

    1. Seekers of Perl Wisdom often post unclearly and have not done any real search, even in the monastery before they post.
    2. Responders to those posts often do not read the post fully!
    3. Often a responder has something he wants to say and he is going to say it regardless of relevance in the particular instance.
    4. Seekers do not always read the answers properly either.
    When I ask a question part of the interest is seeing just how many ways monks can come up with to do the same thing. I am also happy to entertain anybody's particular pet theories, but I also expect that they will explain why it should be done that way. Just that they thought of it is no good reason. As for the module loading question, well, I can understand why someone might want to do it. But is it a good idea? Well, somebody needs to educate the OP and myself alike!

    jdtoronto

Re: Being helpful to a fault?
by YuckFoo (Abbot) on Dec 11, 2003 at 20:53 UTC
    The second is more of a leading question that folks here have probably seen before: When someone asks how to achieve a particular result in order to gain some advantage in their work, and this is likely or certain to create some larger problem, do you just answer the question, or do you point out the larger problem?

    graff,

    I can't possibly imagine why you would want to ask such a question. Especially since you acknowledge that it has been asked before, and have read enough nodes yourself to know how monks answer questions.

    Please give up this endeavor and use Perl's builtin sort.

    HadToFoo