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

I'm feeling a little contemplative today, mostly about very simple subjects. One topic that came to mind is this: What are the top ten things every Perl hacker should know? I encourage you all to offer your suggestions, but I've decided to provide a list of my own as a starting point.

  1. Perl is not an acronym
  2. there is more than one way to do it
  3. how and why to use warnings and use strict
  4. how and why to use taint checking
  5. how and why to use lexical scoping for variables
  6. how saved Perl source code files should be named
  7. how to use CPAN
  8. how and why to use perldoc and PerlMonks
  9. don't reinvent the wheel: how and why to use subroutines, modules, and libraries
  10. how and why to use regexen

I suspect the bit about naming Perl files will be considered less important by others here, but it seems quite important to me to know what file extensions to use for different types of source files, to use names without spaces and special characters in them, and to use at least vaguely descriptive names.

This is meant to be a list of generally important bits of knowledge, like quirks of the language, resources available, and important aspects of Perl culture. It's not intended to include things like ingenious snippets of code or what O'Reilly books about Perl are best (though these, too, are worthy subjects to contemplate).

print substr("Just another Perl hacker", 0, -2);
 - apotheon
CopyWrite Chad Perrin

  • Comment on top ten things every Perl hacker should know

Replies are listed 'Best First'.
Re: top ten things every Perl hacker should know
by xdg (Monsignor) on Mar 16, 2006 at 05:02 UTC
[reply]
Re: top ten things every Perl hacker should know
by grinder (Bishop) on Mar 16, 2006 at 09:40 UTC

    I think you omit a number of things that are of crucial importance

    • Know what the Phalanx 100 is, and study it. It is an excellent starting place for finding out what CPAN has to offer.
    • Know the name of your local CPAN mirror.
    • Know how to install a CPAN module directly without the assistance of cpan or cpanp.
    • Know what mailing lists are available, and subscribe to the ones that you think are important or interesting.
    • Know where the next, nearest Perl Workshop or YAPC will be held.
    • Know how to file a bug report. Does the author like to receive e-mail or do they mention that they prefer to use Request Tracker? (One prominent author refuses to use rt.cpan.org).
    • Know how to comment out large slabs of code easily.
    • Know how and when barewords are interpreted as strings or globs
    • Know what the indirect calling notation is and why it is deprecated.

    • Know what lexical filehandles are
    • Know that a warning in an if statement may well be related to a chained elsif further down in the code.

    Goodness! I'd better stop. I'm up to eleven already.

    • another intruder with the mooring in the heart of the Perl

[reply]
      Know how to comment out large slabs of code easily.
      1. Mark the block to be commented.
      2. Fire up search and replace in regex mode
      3. Search for "^", replace with "#"
      Of course you need a decent editor. The other way round should be obvious ;).


      holli, /regexed monk/
[reply]

        Or better yet, teach the editor to do 1, 2 and 3 (and the inverse) as a macro.

        And for those without a decent editor wondering what to do, I assume the original reference was about using Pod:

        =begin comment

# lots of code here

=end comment

        [download]

        -xdg

        Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

[reply]
[d/l]
        At the risk of starting up a whole new discussion, my vote for a decent editor goes to nedit.

        Cheers,

        JohnGG

[reply]
Re: top ten things every Perl hacker should know
by radiantmatrix (Parson) on Mar 16, 2006 at 15:19 UTC
[reply]
My top ten
by DrHyde (Prior) on Mar 16, 2006 at 10:25 UTC
    1. All rules are guidelines, including this one;
    2. Always use strict and use warnings;
    3. use constant is your friend;
    4. Regexes are bad, you can often use another way to do it;
    5. While there are many ways to do it, most of them are wrong;
    6. Anyone listing rules for programmers is wrong;
    7. Documentation is for users, comments for developers. You will be a user of your own code, so selfishness compels you to write both;
    8. Tests aren't as necessary as the testing cabal would have you believe;
    9. Tea is the one true source of caffeine;
    10. It's OK to reinvent the wheel sometimes;
    11. There will always be last-minute additions
    My second rule is really just a variation on "turn on the fascism options in your compiler; and if the compiler emits warnings that's because your code is broken". My third rule is a special case of general good practice regarding naming conventions.
[reply]
      Rewrite for #7

      Users don't read documentation if they have a phone number. Write documentation like you would a mystery novel, and leave clues to your phone number spread out through the documentation. That way, by the time they've figured out your phone number, they've already got their answer and they don't need to phone you.
[reply]
      Jolly well done, except for the utter nonsense in point 9. Tea is fine as a supplemental source of caffeine, but nothing more.
[reply]

      re: "10. It's OK to reinvent the wheel sometimes;"

      I'd say that's generally only true if you can't get at the source for the wheel. Really, wheels should usually be improved rather than reinvented anew. One might also consider whether wheels simply need new tires (wrappers) rather than reinvention, though the outer interface for the wheel might need to be redesigned to accept your new tire design.

      There are exceptions to every rule, including the "use strict and warnings" rule — particularly in Perl culture — but I don't think that invalidates the rule particularly.

      print substr("Just another Perl hacker", 0, -2);
      		 - apotheon
      CopyWrite Chad Perrin

[reply]
        I strongly disagree.

        Just because someone else has written a piece of crap, doesn't mean that I have to use it.

        In fact I'd say that one of the critical programming skills that few develop is being able to properly decide whether to reuse or ignore a particular wheel. It isn't an easy decision. And it certainly isn't as simple as saying, Always do _____.

        The advice to always reuse wheels is good advice to give beginners exactly because they are beginners. Wheels that they're likely to hear about from experienced programmers are always going to be better than what they can write for themselves. But good programmers have a harder decision to make. Because if you actually are good, you probably can create better wheels than a lot that are in use out there. The question then becomes whether it is worth the time and energy to do so. Usually it is not, but sometimes it clearly is.

[reply]
        Sometimes the guts of a module are so tied to the interface that to adapt it means to rewrite it anyway, in which case it's usually quicker to just write a new module than it would be to pick the old one apart and then hack it up beyond recognition. A good example is GD::Graph, which I am very seriously considering re-writing to add some features and fix others.
[reply]
Re: top ten things every Perl hacker should know
by jcoxen (Deacon) on Mar 16, 2006 at 14:08 UTC
    A non-programmer, beginner's take on this...

    1. Always use strict.
    2. Always use warnings.
    3. Always use diagnostics during development.
    4. KISS.
    5. Brute Force programming is not always a bad idea. Elegant code is often slower and harder to maintain.
    6. White space is your friend.
    7. Comments are an even better friend.
    8. CPAN is the best friend you'll ever have.
    9. When you've programmed yourself into a corner, sometimes the quickest fix is to trash everything and start from scratch.
    10. Assume that the person who will have to maintain your code is even more of a NOOB than you are.

    Jack

[reply]
      Brute Force programming is not always a bad idea. Elegant code is often slower and harder to maintain.

      I agree with the first premise. The supporting reasons are less good. A complicated Schwartzian transform may well be impossible for a first-year Perl hacker to read but it's 100 times easier to read than the 2 screenfuls of code it replaces if you know what it is. Elegant, to me, means better, concise, more lucid, not too tricky to follow.

[reply]
        There's a difference between elegance for elegance sake (ie. doing something tricky because it has a high geek factor) and elegance because it's good programming (e.g. the Schwartzian transform). I was thinking more of high geek factor code. It might parse better if I s/often/sometimes/.

        Jack

[reply]
        Bad example.

        A Schwartzian transform in Perl is always more complex than a straightforward sort block. It is good to know about it because it can be lots faster, but it is more complex.

        If you do not understand this, then you don't really understand the Schwartzian transform.

        (Note that I have to say "in Perl" because other languages, for instance Python and Ruby, have implemented shortcuts to make Schwartzian transforms simpler than the alternative.)

[reply]

      When you've programmed yourself into a corner, sometimes the quickest fix is to trash everything and start from scratch.

      That's very true — but it's also sometimes instructive to keep doggedly at the problem until you solve it without rewriting, even if scrapping the original and starting over would be quicker. That's my experience, at any rate.

      print substr("Just another Perl hacker", 0, -2);
      		 - apotheon
      CopyWrite Chad Perrin

[reply]
      10. Assume that the person who will have to maintain your code is even more of a NOOB than you are.

      I think its reasonable to assume that the person who has to maintain your code is at least an average Perl programmer. The purpose of coding, commenting, and documentation isn’t to teach Perl to beginners.
[reply]
        If you're in a programming shop then maybe that's a reasonable assumption. However, I work with a bunch of Telecommuncations engineers. One of the guys is pretty good with MS-Access and VB Script but I'm the only person in the group that knows anything about Perl. And I am not a programmer. The last time I did any serious programming it was on an IBM 360 in PL/1 with punch cards. I'm a general computer/network geek that got saddled with the programming tasks because I'm the resident "Data Guy". In a situation like mine, it's NOT reasonable to assume that the person who comes in behind me one day will know any more Perl that I did when I bought the Perl Bookshelf CD lo these many months ago.

        When my boss asked me to take this on, the primary focus was to update some scripts that had been written by one of the IT guys who had since left the company. Trying to figure out what he was doing was next to impossible since he had written the code assuming that he would be the only person to ever maintain it - or so I assume since he didn't indent, didn't use whitespace and didn't comment anything...ever. I had to figure out what groups of programs to look at based on their file names and when they ran - "This output file has a creation time of 20:38 so I'm looking for a program that runs sometime before that."

        I have to agree that comments and documentation aren't supposed to be a tutorial but it's nice when a) they exist at all and b) they are comprehensive enough that you can follow the general flow of the program without having to read the code.

        Just my opinion...

        Jack

[reply]
        I think its reasonable to assume that the person who has to maintain your code is at least an average Perl programmer. The purpose of coding, commenting, and documentation isn’t to teach Perl to beginners.

        That's making a vastly unwarranted assumption.

        Look at the most junior person who is (not "should be, if only my boss would listen", but who is) assigned to maintain perl code: and always ensure that they will be able to read what you write.

        An expert can always decipher simple code; a novice often can't decipher "clever code". Programmer time is expensive: don't waste it. Even if it takes 10% longer to simplify your code style (and it probably doesn't, if you're good): it's probably just plain cheaper to write code maintainable by the novice, unless it's going to incur a business cost in terms of performance (unlikely, but possible in some cases). Remember, senior programmer time is expensive: anything that someone lower paid can do is (a) work you're not tied up with, and (b) puts available resources to work productively.

        In short, do what's right for your company: not what fits your preconceptions of what a programmer "should be". They're often not the same thing at all...

[reply]
        I think its reasonable to assume that the person who has to maintain your code is at least an average Perl programmer. The purpose of coding, commenting, and documentation isn’t to teach Perl to beginners.

        Not according to every anecdote I've run across, including those I've been personally involved in. When I was contracting at a large outsourcing firm, my maintenance tasks included SAS, PL/1, and COBOL code. I had never even seen code in any of these before. A much better assumption than assuming the person who has to maintain your code is an average Perl programmer is assuming that she|he will be trying to make sense out of code with Learning Perl in one hand and a jar of ibuprofen in the other

        emc

        " The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents."
        —Nathaniel S. Borenstein
[reply]
Re: top ten things every Perl hacker should know
by Juerd (Abbot) on Mar 17, 2006 at 13:39 UTC

    Apply grains of salt :)

    1. Perl rocks!
    2. PHP sucks!
    3. Java sucks!
    4. VIM rocks, Emacs sucks! (alternatively: Emacs rocks, VIM sucks! *)
    5. Perl 6 fixes everything
    6. A camel in Perl context can only be used with permission from O'Reilly
    7. There's also onions
    8. Patches welcome!
    9. EFnet #perl is not a help channel
    10. TIMTOWTDI, but only one is the best way

    * As long as you pick sides

    And, about Perl Monks specifically:

    1. merlyn wrote an article about it
    2. It's tye's fault, but you can blame ar0n
    3. The gods are always right
    4. No, it can't be made faster
    5. Almost everything is set in stone
    6. The sections that we have now are perfect, thank you
    7. If you get more XP than vroom, you get immortality
    8. The assimilation by TPF is forever recent
    9. There is more than one way to scrape PM, and XML may not be XML
    10. Your password is not safe here

    Oh well, here's a CPAN list of things you should know:

    1. If you upload to CPAN, you are famous
    2. Modules without recent release are bad
    3. Bogus tests are better than no tests at all
    4. Kwalitee is linked to your karma
    5. Discuss it on the mailing list first
    6. Just don't expect any useful response
    7. After years of development, search.cpan.org now finds DBI if you search for "DBI"!
    8. There is more than one module that almost does what you want
    9. RTFM
    10. CPAN is an archive, but you're supposed delete old stuff anyway
[reply]
[reply]
      Re. salt grains no. 4, they both suck and nedit rocks :-)

      Cheers,

      JohnGG

[reply]
        BTW, did you try my nedit perl calltips and macros ( just curious)?
[reply]
Re: top ten things every Perl hacker should know
by Anonymous Monk on Mar 16, 2006 at 00:21 UTC
    1. Perl is not an acronym
    This is the top item on your list? On my list, that's at number 101,439. Right after "Learn to turn on computer".
[reply]

      It seems like an important item if you're going to converse with other Perl programmers. Calling it PERL instead of Perl is a quick way to get marked as a know-nothing newbie — which is doubly problematic if you're an author of programming instructional texts. I've seen an awful lot of Perl books wherein the author kept calling it PERL.

      Then again, you're right: this item is pretty frivolous, in the grand scheme of things.

      print substr("Just another Perl hacker", 0, -2);
      		 - apotheon
      CopyWrite Chad Perrin

[reply]
        It's minor, sure, but it drives me batty that I have an infrastructure diagram where it is spelled PERL. In spite of how many times I have told them to change it. I think its a conspiracy to piss me off :-D

        no, i'm not paranoid - it's just that they really are out to get me ;-D

[reply]
        Calling it PERL instead of Perl is a quick way to get marked as a know-nothing newbie 
        %man perl
NAME
      perl - Practical Extraction and Report Language

        [download]

        You're right... only an idiot would consider that an acronym. No wait -- only a perl cultist wouldn't consider that an acronym, because that's exactly what it is, and only severe abuse of one's perceptions and/or the English language itself can change that.

        However, not everyone is a perl cultist. Some of us don't believe in abusing the honorific case in English to distinguish a language from it's implementation, because unlike gods and royalty, a mere programming language doesn't deserve genuflection, and to those speakers of the English language, "Perl" is only correct if capitalized at the beginning of a sentence.

        I realize this place is called Perl Monks, and that some people think it grants them license to turn into foaming at the mouth perl fantatics, but seriously -- denying the very truth before your eyes is the mark of a cultist, not a rational human free of the taint of religion.

        Perl *is* an acroynm, because of the very fact it's been billed as such for well over ten years. Just because Pope Larry has decided to pull back from some of his past decrees doesn't undo the past.

        Drop the religious fervour; it's not serving any purpose. Be rational, and focus on writing quality code in the language, and follow the original rules for the English language, not PerlSpeak.

[reply]
[d/l]
        Not this shit again...:(

        thor

        The only easy day was yesterday

[reply]
Re: top ten things every Perl hacker should know
by Scott7477 (Chaplain) on Mar 16, 2006 at 04:25 UTC
    Okay, I'm intrigued. Please explain your thoughts on how Perl source code files should be named and why,
    or perhaps show a link to your writings. I've been debating how to do this since I started downloading
    code from this site recently.

    Thanks....
[reply]

      Perl source files (for scripts, not modules) should be named like whatItDoes.pl and checked in to source control. And you should have a script that "installs" your Perl scripts so that you can run them. That install script should do the following:

      • adjust the path in the #! (unless you are lucky enough to have enough control of all of your systems so that /usr/bin/perl is always appropriate as Larry intended)
      • copy the file into the appropriate directory in your PATH
      • rename the file so it no longer ends in ".pl" so that you execute it simply as "whatItDoes", like every other command you use (because a tool getting reimplemented in a different language should not cause you to have to invoke it any differently)
      • set execute permission (for some OSes)
      • run pl2bat (for other OSes) -- Note that some prefer other ways of making it so that, on Win32, you simply invoke a Perl script using an extensionless name (not "perl ..." nor "whatItDoes.pl ...") and I'm not arguing against such alternatives; I'm simply arguing needing to know what language the whatItDoes tool was written in in order to use it is a mistake. (:

      Though certainly not necessarily in that order, or even as that many steps.

      - tye        

[reply]

        Good list, but for

        rename the file so it no longer ends in ".pl"

        I think I'd prefer to create a link (hard or soft, whichever you feel more comfortable with) from whatItDoes to whatItDoes.pl, leaving the original file as it is. Only for those OSes that can do links of course.


        All dogma is stupid.
[reply]
[d/l]
Re: top ten things every Perl hacker should know
by nothingmuch (Priest) on Mar 19, 2006 at 07:25 UTC
    My list is:
    1. Balance is everything
    2. Why and how to use the CPAN
    And all of their dependencies.

    By the time a Perl hacker reaches the point where they can use the CPAN effectively they have significant technical skills and cultural know how.

    When said hacker is then starting to pass good judgement on effort vs. gain, complexity vs. simplicity, and all of those topics we have such a hard time with I think that J. Random is ready to take the final journey. This stage is much more intangible than any other learning stage, and is often walked alone, but arguably it's the stuff that makes you into a "real" programmer.

    I don't think this journey ends, btw ;-)

    We have a word for these kinds of musings in hebrew - it's the combination of the roots for philosophy and flatulence.

    -nuffin
    zz zZ Z Z #!perl
[reply]
Re: top ten things every Perl hacker should know
by spiritway (Vicar) on Mar 17, 2006 at 04:38 UTC

    I disagree slightly about "don't reinvent the wheel". If you need to get a job done, and there's already a tool that does it, then I agree - use it. But I do think there is a place for taking a crack at a problem, even when there are good solutions available. It helps to know what's involved in solving the problem, which could help you better choose which solution would serve you best. It can open you up to new ideas about programming. If the solutions don't quite fit your needs, you can make changes. And, it can be fun.

    Often, professional programmers simply don't have the luxury of doing this. The PHB doesn't want them dithering around *learning* things, when they could be doing useful work. But if you've got the time, it's not always a bad idea to reinvent the wheel, if only to appreciate how well someone else made one.

[reply]
      Sometimes the existing wheel doesn't quite do what you need it to do so you need create an alternate wheel :-)
[reply]
Re: top ten things every Perl hacker should know
by virtualsue (Vicar) on Mar 19, 2006 at 13:57 UTC
    1. Perl is not an acronym
     

    <prisoner>
       I am not an acronym, I am a free language*!
    </prisoner>



    *Offer void where prohibited, and subject to certain terms and conditions. YMMV, HAND :)
[reply]
Re: top ten things every Perl hacker should know
by ghenry (Vicar) on Mar 16, 2006 at 13:00 UTC

    "Perl Programmer" sounds better than hacker ;-)

    Walking the road to enlightenment... I found a penguin and a camel on the way.....
    Fancy a yourname@perl.me.uk? Just ask!!!
[reply]
Re: top ten things every Perl hacker should know
by Scott7477 (Chaplain) on Mar 16, 2006 at 13:46 UTC
    A very useful discussion from my point of view. Each of tye's points makes total sense. tirwhan's caveat is understandable. Since
    different folks' ideas of what is most important are going to vary, it's worthwhile to see the different responses. I have found that
    in thinking about a specific subject, whether it be Perl or any other topic, putting together a "top ten list" can be a useful problem-solving exercise.
[reply]

Back to Meditations