Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine

Comment on

( #3333=superdoc: print w/replies, xml ) Need Help??
I spend a lot of time helping (or often just trying to help) people learn Perl in various places. Over the years, there have been so many common threads that emerge from the endless flow of beginners that I have recently been trying to put them to paper. I thought I would share with you all some common misconceptions that I encounter, at best, on a weekly basis and, at worst, hourly. So without further ado...

1. Everyone who goes through the trouble of writing a Perl tutorial must know what they are talking about.

The Internet is a wonderful place, full of information on every topic you can think of. With google, who can go wrong? Heck,you just typed in 'PERL tutorial' and got 5,000,000 hits, surely you can learn something from that veritable avalanche of data. You click the first link and start learning. You immediately learn the basics, such as how to call subroutines (&subroutine, obviously), how to do type checking on sub arguments (prototypes!), access elements from an array (surely, it's @array[5]). You decide to branch out a bit and navigate your way to another tutorial that tells you right off the top that every program should start with 'use warnings;'. You try this and your program suddenly complains to you loudly. You say 'this guy doesn't know what he's talking about', switch off warnings and go on to another tutorial that teaches about the power of symbolic references.

Wrong! You have been duped. You stumbled upon one of the many utterly horrible tutorials out there. I don't think I can stress 'many' enough. Certainly the majority of tutorials will mislead you, lie to you, teach you broken concepts, and basically waste your time (I mean in the grand scheme of things; despite your complaints that you were able to complete task A by reading internet tutorial B). Please see the references at the bottom to find some good starting places.

2. Prior experience in another language makes you qualified to write perl without learning the basics.

You've written COBOL for 25 years in an IBM iron shop. You've got REXX down pat. You even wrote some C code once that holds together a critical part of your organization's infrastructure. You learned Java from a Java grand wizard and have contributed code to the standard library. You wrote a distributed backup system in bash. Your boss says 'Hey Johnny, we need you to write a CGI application in Perl ASAP' You say 'No problem, boss'. You can do anything. You are a programming wizard.

Wrong! Prior experience in programming languages may be very helpful when learning a new language, but it doesn't mean you know how to properly express yourself in said new language. There may be many common idioms and concepts that apply in nearly any language you will encounter, but you will not know how to apply those idioms properly in a new language without understanding the basics. Perl is no exception to this and it must be clearly understood that the ability to apply a subset of common idioms from another language to a new language does not preclude the necessity for learning the basics. Do yourself a favor, get a book, skim through it. Learn how to find what you need in the documentation. Refer to the documentation often.

3. The documentation is terse and hard to navigate.

You are on chapter 4 of Beginning Perl and you decide that it's time for you to put some of your knowledge to practice and start coding a blog system. You check out a few other blog systems written in perl and get some ideas about what you want to do. You are reading someone else's code and you see '$foo->{bar}->($baz)' and your eyes just about bug out of your head. What the heck is this thing? It looks sorta like perl variables, but what is this '->' thing?

You jump on IRC and decide to ask the grumpy guys in #perl what it means. Fifteen minutes pass and someone says '<perlguy> RTFM! perldoc perlref'. 'Ah, yes, perldocs' you say to yourself while opening a command window. You type 'perldoc perlref' and stare at the screen confused. This looks like a man page. You hate man pages. You hate reading documentation; it's boring. You decide you don't really need to know what '->' is anyway and never return to the arcane library of Perl knowledge called 'perldocs'.

Wrong! The perldocs are voluminous, true. The perldocs are (arguably) ugly, true. The perldocs look like man pages, true. However, they are chock full of factual information about the language and additionally interspersed with many useful tidbits placed there lovingly by the Perl wizards who wrote them. They also happen to be the authoritative source of information about the language. It's intimidating to you because you are a beginner and haven't put all the Perl pieces together enough to be able to disseminate the docs into quick answers for yourself. Don't worry, this understanding of the perldocs will come with time, but it's like anything, you have to practice even when you aren't any good at using them. (or making use of them) If you make a conscious effort to perldoc every function, module or concept you don't fully understand you will eventually reach a deep understanding of how to navigate them. It will be effortless. You will have elevated yourself to a new plane of Perl understanding.

4. The Perl community is an automatic answer machine.

You are meandering down the road of learning Perl. You have a problem with 'one little thing'. You decide to go ask the Perl community for help. They ask you broad questions about your problem that don't seem to apply directly to 'one little thing'. They point you to documentation that doesn't spell out specifically how to solve 'one little thing'. They critique the way you've designed your program in general or structured your code and offer hints on parts of your program that are seemingly unrelated to 'one little thing'.

Eventually someone gives you a direct answer to solve 'one little thing'. You say 'Ah HA!' and go back to your isolated programming world forgetting all about everything leading up to your 'Ah HA!' moment aside from the fact that a bunch of people wasted your time with irrelevant information when all you needed was the solution to 'one little thing'.

Wrong! The Perl community is a wonderfully diverse collection of people with a tremendous amount of experience and wisdom. All of those people 'wasting your time' were actually spending their own valuable time helping you with problems you didn't know you had yet. They were trying to give you the tools and knowledge necessary to solve the next 'little thing' yourself in a much more expeditious way. They were trying to draw you into discussion so that you could become acquainted with and participate in our community. Don't take their advice for granted, use it, apply it and then contribute your own advice when you can.

5. Modules are a crutch for people who can't do it themselves.

You decide to write an IRC bot. Maybe you check out RFC 1459, maybe not. You telnet to an IRC server and mess around with the protocol by hand. You ask for advice from the Perl community and they reply with 'check out POE::Component::IRC' or 'Bot::BasicBot'. You think to yourself, 'Why would _I_ need to use someone else's module to do this? I don't need anybody's help! Damn all modules to hell!'. You snicker quietly, type in 'use IO::Socket::INET;' and start programming.

Wrong! Whether you've decided to reinvent yet another oft invented wheel because of ego or because you want to 'learn from the ground up', you've made a terrible mistake in not tapping into the tremendous amount of Perl community developed and supported modules. CPAN is brimming over with excellent modules written by wise, experienced programmers. (And also few not-so-excellent modules that were written by not-so-excellent authors, but that's another story) Even if you want to learn how to implement an IRC client from scratch, would it not be advisable to at least review how other people have approached the problem? If you have a project that you need to put together quickly, would it not save you a lot of time (and possibly money) to make use of something that's already there?

Modules are a good thing. Code reuse is a good thing. These are not concepts specific to Perl. Do you know of any C programmers who don't use 3rd party libraries? (Ever) Do you know of any java programmers who write XML parsers by hand? No, they make use of the community supplied wheels that have already been invented for this task. You should make use of them too. Don't be concerned that people won't respect you for using other people's code, rest assured that people will applaud your righteous laziness and efficiency! Go forth and use modules!


Learning Material:
Start here! Lots of great, authoritative information on picking up perl.
You will undoubtedly find this if you browse around enough, but I thought it warranted a distinct entry. This is a free and _very good_ (previously published) book that has been graciously made available to the Perl community. (Thank you Wrox and Simon Cozens!)

You're here NOW ain't you?
The top level portal to all things Perl. is just plain full of great subdomains.
The CPAN. Use it. Love it. Live it.

In reply to Five Common Misconceptions While Learning Perl by m.att

Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":

  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.
  • Log In?

    What's my password?
    Create A New User
    [Sinistral]: nail in coffin was the rant against a Schwarzian Transform
    [stonecolddevin]: at best, from what i've seen, his knowledge is accurate up to maybe 2002. the sheer volume of words is mostly worthy of a downvote in most cases though i think
    [erix]: ITYM Schwartzian Transform :P
    [erix]: hey planetscape :)
    [planetscape]: howdy stonecolddevin, erix
    [Sinistral]: eric Aye. I thought I typed that wrong. All hail Randall! I listen to him on FLOSS Weekly
    [Discipulus]: i think his vacuus, trombon like, absence of meaning, joined with a ostentatious style, after many years irritates the most
    [erix]: easy to get wrong -- I guess that was sund's point, too :P
    [Discipulus]: planetscape welcome back! (or is well comeback?)
    [Discipulus]: fore every 2 good old monks that come back, we will accept 1 clinical

    How do I use this? | Other CB clients
    Other Users?
    Others wandering the Monastery: (8)
    As of 2017-06-22 21:00 GMT
    Find Nodes?
      Voting Booth?
      How many monitors do you use while coding?

      Results (530 votes). Check out past polls.