Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked

Things learned from Perl Monks

by AcidHawk (Vicar)
on Sep 16, 2002 at 12:25 UTC ( #198226=perlmeditation: print w/replies, xml ) Need Help??

If there is one thing I have learned from my short time here at Perl Monks (and there must be a million but probably the most important thing), it has to be the value of using strict and warnings. In many many posts on the SOPW area, I all to often see the recommendation to use strict and warnings to point the user in the right direction.

I for one can't believe that people still don't use them. I do sometimes find it a little difficult to understand the error that is reported but sure as hell I'll know there is a problem and if I don't understand the error I will be pointed to the line that has the problem.

I have no formal background in programming and often take ages to find where I have made a silly if not bad mistake in my code. Using strict and warnings definately has helped me re-look at a LOT of my code and as a result I am starting to understand more and hopefully write better code.

So for my two cents, use strict and warnings as a newbie...It has definately helped me.

Of all the things I've lost in my life, its my mind I miss the most.

Edited: ~Mon Sep 16 16:28:53 2002 (GMT) by footpad: Moved to Meditations, per Consideration.

Replies are listed 'Best First'.
Everything I need to know I learned from PM
by charnos (Friar) on Sep 16, 2002 at 13:03 UTC
    Very insightful. I think if there were one thing most monks could successfully convey to all new users, it would be that concept. Even if you can't understand the warnings or errors all the time, the information provided is invaluable when seeking the assistance of those more learned than you, as I have found out. The purpose of these tools appears to me as threefold.

    The first I just described: giving others with more experience in the trenches a starting point for where to look to begin helping

    Secondly, if you don't understand the error, at the very least you will reevaluate all that you've written (or at least start with a section of suspected problem code) to try to rectify the problem.

    Lastly (and this is in direct conflict with one of the three axioms of programming ;-) ), if you have patience and steadily progress while working with strict and warnings on, you'll begin to understand what the errors mean, why they pop up, how you can get around them doing a similar task in the future, etc.

    My two cents is this, nothing said in this thread is new information. It's invaluable, but certainly not original. To new monks: there is a wealth of arcane knowledge of programming, computer science theory, and of course Perl to be gained from the Tutorials, use it. Many have worked hard to enlighten others to the True Path, take advantage of their insight, it is vast.
Re: Things learned from Perl Monks
by Elgon (Curate) on Sep 16, 2002 at 16:48 UTC

    AcidHawk and others,

    I'd certainly have to agree on the use strict; and -w points but there is so much more available here than these, admittedly highly useful, points.

    Monks (in general) are helpful but the best lead you to where you need to be to find the relevant knowledge rather than just give it to you on a plate. I find this probably the best way of learning as this helps me to understand what is going on rather than simply to know it.

    At the moment I am working on making my Perl more fluent in nature; eliminating intermediate, temporary values and trying to string things together into more of a coherent process and less of a lurching, stepwise method. One comment which helped me was Merlyn's exhortation to do away with intermediate variables if you could not in good conscience give them a name which really reflected their purpose as this tends to suggest that they aren't needed.

    PM has definitely helped to develop my Perl from baby talk into its current state of adolescence and hopefully to adulthood at some point in the future.


    "Rule #17 of Travel: Never try and score dope off Hassidic Jews while under the impression that they are Rastafarians."
           - Pete McCarthy, McCarthy's Bar

Re: Things learned from Perl Monks
by Nemp (Pilgrim) on Sep 16, 2002 at 18:21 UTC
    Hear, hear! AcidHawk

    Although having read your post and had some time to digest its content and the replies there are a few things that I would like to add as my personal "Things learned from Perl Monks" being another young-timer here :) (Can I use that? People use old-timer after all...)

    First off I agree wholeheartedly with the posts that mention use strict and -w or use warnings. I also agree with charnos where tutorials are mentioned. Just to try and get my own personal experience across, search for an answer, look in tutorials, find a great tutorial in tutorials and use the tutorial to further your knowledge!! "Wonders if he got his point across sufficiently there..."

    Oh and if you can't find something of relevance in tutorials take the time to go and look in the library too! The material there is priceless!

    To re-iterate... my lessons learned here would be;
    • use strict; and use warnings or -w
    • Look in the tutorials section because it's great!
    • Look in the library section becuase it's great!
    • Participate in the incredible community that has grown up here - make the most of it to both help with your problems and to help others where you can.
    Just my $0.02,

    Update: My other lesson which I forgot to include would be: Listen to and take heed of any good advice given to you, there are a lot of very experienced posters whose tone may not always seem friendly (especially if you offer a hopeless solution ;)) but who are here to try and help!
Re: Things learned from Perl Monks
by Daruma (Curate) on Sep 16, 2002 at 16:51 UTC

    I must agree with AcidHawk... use strict; and use warnings; would rank very high on the list of things learned from my time (mostly lurking) on As a matter of fact, I have revisited most of my older perl code and applied the wisdom and direction of use strict; and use warnings;. (Wow! I had some nasty code!)

    I had hacked about and scripted with perl for a little while. Then I found The Monastery. I have discovered a vibrant community with a great deal to offer. I have spent more time reading and researching for my answers than I have posing questions. Most of the questions I have needed answered for making my code work has been found in previously established nodes. I'm also honored and pleased to find myself in the presence of some very skillful perl coders.

    Above all, I enjoy the fact that I learn a little more about perl and its usage every day.

Re: Things learned from Perl Monks
by seeker (Curate) on Sep 16, 2002 at 18:15 UTC
    One point here;

    So for my two cents, use strict and warnings as a newbie...It has definately helped me.

    Using strict and warnings are not just for newbies. We are all very senior programmers where I work, and every one of us uses them both. All the time.

    It not a something that needs to be outgrown.

Re: Things learned from Perl Monks
by Vennis (Pilgrim) on Sep 16, 2002 at 12:56 UTC
    strict, warnings, Search, amen. :-)
Re: Things learned from Perl Monks
by Anonymous Monk on Sep 16, 2002 at 22:26 UTC
Re: Things learned from Perl Monks
by helgi (Hermit) on Sep 17, 2002 at 11:33 UTC
    I certainly agree with using warnings and strict. Hell, nowadays I sometimes even catch myself using them in one-liners! ;-)

    A couple of other things that help both newbies and the experienced to catch more errors, are:

    1) Always return filenames and errors and die or warn when system operations fail ,i.e.:
    open IN, $in or die "Cannot open $in:$!\n";

    2) Always give your variables meaningful names. Always. If you can't, you don't understand the function of the variable well enough to be allowed to use it. This of course, applies equally to subroutines. A variable named $foo or $x in code over 10 lines in length is usually the sign of crap code.

    3) Code is for humans to read. The fact that it is read by a machine as well is incidental. Always code with the thought in mind that someone else will maintain your program in the future. How I have cursed people in the past who failed to do this.

    Helgi Briem

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://198226]
Approved by footpad
Front-paged by footpad
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (11)
As of 2018-03-23 13:51 GMT
Find Nodes?
    Voting Booth?
    When I think of a mole I think of:

    Results (293 votes). Check out past polls.