I am a newbie (by my standards). I was watching some PerlMonks chat the other day and something quite interesting occurred to me that I thought I would share with the rest of my fellow monks.

This is not so much directed toward those who know Perl as much as it is toward those who don't know as much as they would like to know. As a newbie, I, myself, tend to think that one can learn the finer points of perl coding by attempting to write one's own code without the use of too many or any modules. This just makes sense to me. It is like trying to put a puzzle together but instead of putting it together piece by piece, someone came before you and put all but four quadrants together. Albeit, its not quite that easy. I also admit that its almost ridiculous to try and write your own basename() subroutine instead of using File::Basename *but* that is exactly my point. If a newbie would attempt to write such a subroutine I would think that that coder now knows the finer points of certain aspects of coding in Perl.

This is just my opinion. It logically seems wiser for newbies to *not* rely on modules for use but to *rely* on modules for learning. Heh, it sounds like I am not advocating modules and that is not the case at all. There is a point where it is plain obsurd to re-invent the wheel. I suppose I can sum it up like this:
I do not think it is wise for those of us who know next to nothing about Perl to rely on modules when we don't even know how those modules do what they do and therefore, do not make use of the basic knowledge of Perl coding but instead make use of a module that does all the hard work for us and at the expense that we don't know how it was done. In fact, I can express this opinion for just about any language. C is a perfect example. Once libraruies are built we have the ability to use these libs for our own use which is excellent. But, how many times do we use these libraries and not have a clue how they are being implemented?

Anyhoo, I just wanted to share that idea with everyone and see what others think. Perhaps I am way off base but I don't think so. Again, I cannot stress more that I advocate the use of modules but I think it would be an extremely useful learning tool for us newbies to examine, read, and learn how these modules work so that we can code new modules, complex modules, and scripts ourselves. I feel if we rely too heavily on modules, perhaps we will not know how to code basic Perl anymore. We'll be relying too heavily on modules =P.

----------
- Jim

Replies are listed 'Best First'.
Re: Newbies and Modules...
by chromatic (Archbishop) on Jun 28, 2001 at 09:54 UTC
    I understand what you are saying. You don't want to rely on prepackaged solutions so much that you don't have the opportunity to learn and to improve. That's a good attitude to have.

    On the other hand, if you roll your own recursive file finding algorithm or (and you all knew this was coming) a CGI handler, you'll have something that works in 80% of the situations with very little effort. Unfortunately, the other 20% of the time, it'll take ten seconds for someone in the know to point out where it breaks. I don't want to spend the next week reading three or four RFCs and guessing at what's broken in a sea of web browsers, robots, servers, standards, angels and daemons.

    At some point, both of us have to get our work done. That doesn't mean that I didn't take apart File::Find the other night, trying to put a nicer interface on it, or that jlp didn't rip out most of CGI so we could make it sing and dance a little better. Heck, some people here have even read the Perl source code in spots. (Other spots I wouldn't recommend.)

    I'm all for learning. Download the module. Read the code. Figure out what it's doing and why. I'm just not going to advise people that before they get any work done they need to build their own computer, install Linux From Scratch, delete Configure.sh and write their own Makefile before they can feel comfortable downloading something like LWP.

    There may be a handful of third graders who could write a passable sestina, but let's give them a chance to copy stuff from the chalkboard before we push them too hard.

[reply]
      hahaha....well put. :) But I think we both understand exactly where the other is going.

      ----------
      - Jim

[reply]
Re: Newbies and Modules...
by Beatnik (Parson) on Jun 28, 2001 at 10:02 UTC
    In my newbie days, which aren't that long ago, I had several reasons for still not looking into Modules properly.
    • First off, I was lazy. Too lazy to sometimes dig thru the POD.
    • Second, using exotic modules in scripts (I do mean CGI scripts) can break em, if those modules aren't (properly) installed (which is usually the case with newbie setups/users). Try convincing one of those free hosts' admins to install a big chunk 'o' module for ya.
    • Third reason is ofcourse that I wanted to learn how to program something similar (aka reinventing the wheel), and ofcourse die trying :) There's nothing wrong with reinventing the wheel. People have been doing it for centuries, reinventing the wheel is what software is all about. There is ofcourse a time when you have to realize that you suck at reinventing wheels, and that you'd better stick to using (*thing* *Commercial*) Pirelli (*thing* *Commercial*) tires.
    • I'm sure I left out a gazillion other reasons I had.
    The dilemma I'm having on regular basis is thus, will using a module (that's not part of the standard distribution) stop people from using the script if they can't install it painlessly.

    Greetz
    Beatnik
    ... Quidquid perl dictum sit, altum viditur.
[reply]
Re: Newbies and Modules...
by footpad (Abbot) on Jun 28, 2001 at 19:38 UTC

    I think this is a dangerous idea. I recognize that there is value in learning how things work, but I believe that value lies in learning how to trust that which is already known to work.

    Consider, for example, basic math classes. In geometry class, you're taught how to prove basic theorems, not because there is doubt about the theorem's validity, but because there is a specific process to learn and a set of known theorems that must be trusted to get to the good stuff. I found this frustrating at the time because I never liked having to repeat someone else's work. When I got into algebra, I started to understand geometry a little better. Trig helped me understand algebra more. The same thing happened in my Calculus classes, each built upon the foundations learned in the previous classes.

    However, that was school. Since programming most often occurs in a business environment, the goals change. Yes, you're learning new skills, but you're also trying to produce an end result for some material or competitive gain. Because it's a competitive arena, results are mandatory for success. You don't always have the luxury, time, or resources to verify (or rewrite) that which is already known to work.

    To that end, you need to have a certain amount of faith in the tools available to you. Certain modules, like CGI, are known to work well. I don't believe it makes sense to re-invent them. Yes, it's nice to master the idiosyncrasies of the HTTP protocol, however, is it not more productive to simply trust that Lincoln Stein understands that process very well and focus on using the values given to you by the param() method?

    Now, not every module is as well-written as CGI. Not every module author is as skilled as Lincoln Stein or Gisle Aas. When dealing with lesser-known modules (or authors), it makes sense to review the source for dangerous practices. It makes sense to study the module's behavior, effects, and performance in the conditions you're working with. If the module appears to operate successfully, then it makes sense to trust it a little more.

    Unlike other languages and development environments, Perl makes it easy to gain this trust because you can get to the source for free. Sure, you have to invest some time in actually reading it, but at least you haven't comitted untold dollars to a vendor based on vague promises. You haven't had to sign a pact with the Dark One for the privilege of viewing (but not touching) source.

    I don't believe it makes sense to reinvent the wheel (or a module) unless you cannot find one you can trust. (Before doing that, however, I would caution you to verify your conclusions by posting a message out here, just in case someone else has already been down that path.)

    Bottom line: at some point, you're going to have to make an decision about your project and the tools you'll use to finish it. If you're not willing to trust the work of others, then you've greatly increased the amount of work you need to do for others to trust your work. And that takes a lot more time.

    On the other hand, if you're willing to trust someone else's work, then you've just saved yourself a lot of time that can then be invested in solving the actual problem at hand.

    So, yes. There are times when it may be instructive to re-invent certain things for educational purposes, however, it may be more cost effective for you to focus your limited production time on solving new problems. Definitely take the time to verify that your trust is well-placed, however, don't cripple your project at the start by reinventing things that already work.

    --f

[reply]
      Excellent. I would like to take your math concept a bit further. The purpose of the classes in which you speak of taking were exactly stating my point. You can't eat the meat until you drink the milk first. You took algebra first which helped you to somewhat understand geometry, then you took trig which then of course made more sense because you took geometry and so and so forth. If Perl newbies always used modules to do everything without ever understanding how those modules work (because modules are simply perl code bundled up to make certain tasks easier) they may not ever learn how certain things could or should be coded. That's all I am trying to say.

      The only time greater things come from great things is when people understand the basic foundation upon which those great things were built. Perl is no exception to this idea/rule which chromatic stated my intentions of this write-up perfectly in the first reply to this write-up.

      This is all I was trying to point out. However, all of your points are very well put and valid. It is probably not too wise to take valuable time in learning why modules do what they do while you are on the line trying to get a production script out for work related purposes. See my reply to LD2 above.

      As for re-inventing the wheel, well, the idea behind re-inventing the wheel making sense or not is, in my opinion, in the eye of the re-inventor. Whether the new (and improved?) wheel was worth the time and effort is something that perhaps only the person who ''re-invented'' it can answer until that person gives that code out to the world for scrutiny. I am positive that the CGI modules written have been massaged time and time again (thus perhaps certain blocks of code having been re-written/re-worked/re-invented) to make these hardened scripts just that...hardened.

      ----------
      - Jim

[reply]
Re: Newbies and Modules...
by toadi (Chaplain) on Jun 28, 2001 at 15:12 UTC
    A bold statement said by a analyst here is:

    Programming is copy pasting. Cos everything is already written. In one or another language...

    Is he right???

    --
    My opinions may have changed,
    but not the fact that I am right

[reply]
      I don't believe so(course, it is possible...), but even if what you are writing has been written prior - it does not exactly mean it was written well OR written to fit your particular situation. I think that is why modules were created in the first place. There was a need for a particular piece of code and it could be useful in different situations. Therefore, someone took it upon themselves to create a module that could be useful for someone else down the road. So, my basic answer to this question is no, I think that's a tad general to say that everything has been created before. But on the other hand, useful functions or routines(i.e. a Module or library) most likely have been created OR will be created to be used by others.

      My opinion on the above topic...is a bit mixed. I don't think using a module is wrong, as long as one understands the logic and fully understand the documentation to be as efficient as possbile using the module. But as a newbie, that's pretty difficult. Being in that situation, I think as long as one understands the concepts behind what is going on - and then writes code to utilize the module, understanding everything else will fall into place in time. Experience with modules helps enlighten the programmer on how to use it most effectively, as well as writing something efficient. If I had time as a newbie, I would do what you suggest snafu - I think it could be an excellent idea and a wonderful learning experience. On the other hand, if I was a programmer who was just starting out in Perl in a job situation and knew there was a module out there that could help me - I'm going to use it due to time constraints and the understanding that they know better than I on how to write a particular routine.
[reply]
        LD2, I agree. I also agree with the others regarding learning on your own time vs learning in the workplace. When time and money are of great concern (is there ever a time when they aren't? (= ) then going the module route makes common sense. On the other hand, I really was talking about learning on your own time as that is usually the best time to learn unless you are like me and like to try and learn by the seat of your pants at work on a dead-lined script.

        ----------
        - Jim

[reply]
      He is right. At least at some level.

      The most productive coders are those that know the body of prior art and are expert a decomposing their current problem into chunks that have been done, and chunks that need some "new art".

      And of course the new stuff must be put together in such a way it is usable off-the-shelf the next time a similar situation is encountered. If you find yourself doing something remotely similar to something you've already done, you should be looking for a way to take your prior work, abstract it up a level, and make it into prior art.

[reply]

Back to Meditations