Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

Five Common Misconceptions While Learning Perl

by m.att (Pilgrim)
on Dec 01, 2005 at 20:29 UTC ( #513422=perlmeditation: 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!

References

Learning Material:
http://learn.perl.org
Start here! Lots of great, authoritative information on picking up perl.

http://learn.perl.org/library/beginning_perl
You will undoubtedly find this if you browse around learn.perl.org 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!)

Community:
http://perlmonks.org/
You're here NOW ain't you?

http://www.perl.org/
The top level portal to all things Perl.

http://use.perl.org/
perl.org is just plain full of great subdomains.

http://www.cpan.org/
The CPAN. Use it. Love it. Live it.

Comment on Five Common Misconceptions While Learning Perl
Select or Download Code
Re: Five Common Misconceptions While Learning Perl
by revdiablo (Prior) on Dec 01, 2005 at 21:14 UTC

    Excellent post. Well written, and agreeable. How did you get in my head like that? :-)

    One thing I like to point out when someone plays the "I'm not using a module because I want to really learn Perl" card: a very important part of learning Perl is knowing when to be lazy. Doing everything by hand may help someone learn how things work behind the scenes, but it doesn't usually help learn how to solve real problems in the most effective way. In other words, not only is reinventing certain wheels usually a waste of time, it's counter-productive to the stated goal of "learning Perl".

      One thing I like to point out when someone plays the "I'm not using a module because I want to really learn Perl" card: a very important part of learning Perl is knowing when to be lazy. Doing everything by hand may help someone learn how things work behind the scenes, but it doesn't usually help learn how to solve real problems in the most effective way. In other words, not only is reinventing certain wheels usually a waste of time, it's counter-productive to the stated goal of "learning Perl".

      Using modules is only worth it if you're good enough at [Pp]erl to debug the flaws in someone else's module; this is usually even harder than debugging your own code.

      And yes, modules can contain bugs. Heck, even the perl binary occasionally has bugs; the more code you can understand and fix yourself, the less you're held hostage to someone else's failings.

      If you have the time to invest in understanding something directly, do it. Using a module is only a sound business decision if you can trust the author to have coded it right; otherwise you're setting yourself up for a pile of extra maintenance and bugfixes. Often, this involves reading and deciphering so much obfuscated module code that you might as well have coded it yourself, in a readible way, in the first place, and saved yourself the mental anguish of dealing with some foreigner's tortured notion of how to write decent English documentation.

      In short, if you want the job done right, you get what you pay for. If you're not willing to code it yourself, you have to check it yourself, and that's not better. Ultimately, you're the one responsible for the solutions you provide, so if you can't guarantee them, you can't trust them.

      Edited by planetscape - fixed the anonymonk's square brackets which were being linkified

        Using modules is only worth it if you're good enough at Perl to debug the flaws in someone else's module

        Extending that idea to code reuse in general, is using perl only "worth it" if you're "good enough" to debug flaws in that? What about an operating system? Or your computer's processor? Sure, all these things can and do contain bugs, but it's still very much "worth it" to use them.

        the more code you can understand and fix yourself, the less you’re held hostage to someone else’s failings.

        The problem with that reasoning is that the more code you write yourself, the more you’re held hostage to your own failings. Much-used modules get a lot of people bumping into all of their quirks; your own code gets much fewer beatings and will take correspondingly longer to straighten out.

        I’ve written about this elsewhere. There are good reasons to roll your own instead of using a module, but most of the time, the factors in favour of rolling your own are far outweighed by the factors in favour of using a module.

        Makeshifts last the longest.

Five Common Misconceptions (Summarized)
by Anonymous Monk on Dec 01, 2005 at 22:14 UTC
    1. Everyone who goes through the trouble of writing a Perl tutorial must know what they are talking about. Everyone who goes through the trouble of writing a Perl tutorial should know what they are talking about. However, Rule 1 ("Other people are a constant source of disappointment") applies to programming, as to all other walks of life.

    2. Prior experience in another language makes you qualified to write perl without learning the basics. Prior experience in another language will give you just enough confidence to shoot yourself in the foot with Perl, repeatedly.

    3. The documentation is terse and hard to navigate. This is false. The documentation is verbose, rambling, riddled with confusing attempts at humor, needlessly complex, and hard to navigate. It is, however, not terse.

    4. The Perl community is an automatic answer machine. False. Tom Christiansen was the automatic answer machine; but he was decomissioned after the CIA watched the movie _War Games_, and grew afraid of Artificial Intelligences like him.

    5. Modules are a crutch for people who can't do it themselves. Again, false. Modules are a crutch for people who can do it for themselves. They allow huge groups of people to suffer from exactly the same set of bugs simultaneously, rather than having to invent their own, distinct, set of customized bugs. This allows exploit writers to target a larger segment of the population, and keeps security professionals employed to stop them.

      ++ #outstanding! :)


      holli, /regexed monk/

      Prior experience in another language will give you just enough confidence to shoot yourself in the foot with Perl, repeatedly.: Excellent point. I think juggling makes a good metaphor for programming in this case. Juggling small balls (using BASIC), juggling bowling pins (using Java), and juggling chainsaws (Perl) all use some of the same skills, but you had better damned well know something specific about juggling chainsaws before you try it blindfolded.

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

Re: Five Common Misconceptions While Learning Perl
by bradcathey (Prior) on Dec 01, 2005 at 22:19 UTC

    Agreed, great post.

    Having said that, I'll take some issue with point #3. I really do think Perl documentation (O'Reilly books, CPAN docs, the lot of them) is not geared towards non-programmers. By "non-programmers" I mean folks who are don't have years of experience, a degree, or are full-time.

    Of course, it might be me. Maybe I'm still running a 4.77 mhz chip here, but I find that I really have to work at understanding a lot of the methods and concepts by just reading the books. I learn by example and there are so view real-world code samples that show how things work. That's why I like PMs--there is a lot of practical stuff here (you might have to dig it out).

    I'm not complaining, I'd just love to find working examples and tutorials for things like CPAN modules.

    As I master them, I plan to add to the Tutorials, but not until I know it's solid. Otherwise I'm guilty of #2 above.


    —Brad
    "The important work of moving the world forward does not wait to be done by perfect men." George Eliot
      I learn by example...
      One of the things that bugs me now and again about learning materials is that some of them only teach it for one learning style. Granted, it would be strange to have 4 versions of "It's OK to slice in Perl", from Visual to Kinesthetic. [And can you imagine the Aural tag: "Read the preceding paragraph outloud to yourself 3 times"??]

      The better materials tend to have some of each where practical, and allow the victim to choose a not-quite-linear path: highlighted summaries for the readers, simple diagrams for the viewers, and examples and puzzles for the practical folk.

      When the Camel Book comes out in a 10 box DVD set, complete with lightning talks for footnotes, and behind the scenes shots of Larry on a Segway talking to a simulation of Carl Sagan, everyone should be covered.

      -QM
      --
      Quantum Mechanics: The dreams stuff is made of

        ...Granted, it would be strange to have 4 versions of "It's OK to slice in Perl"...

        That's one nice thing about PM's Q&A--often there will be several examples.

        ...When the Camel Book comes out in a 10 box DVD set...

        Can I queue that up in Netflix?


        —Brad
        "The important work of moving the world forward does not wait to be done by perfect men." George Eliot

      "As I master them, I plan to add to the Tutorials, but not until I know it's solid. Otherwise I'm guilty of #2 above.": I think that's not an optimal approach. I find that learning is often helped immensely by trying to teach the same concepts to others. Try writing tutorials, preferably in places where they can be vetted by others that know more than you.

      Perlmonks is actually a very good place for such a thing. Choose a subject you know a lot about, but maybe not everything, and write a tutorial about it. When people start responding to you, I guarantee you'll get the tutorial fixed in short order so that any mistakes you made start clearing up very quickly. As a bonus, you learn.

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

Re: Five Common Misconceptions While Learning Perl
by Anonymous Monk on Dec 01, 2005 at 22:30 UTC
    2. Prior experience in another language makes you qualified to write perl without learning the basics.
    Er. I'll take exception to this notion. In fact that is the essence TMTOWTDI and DWIM. You need to look no further than languages like Prolog and Haskell to see how true that is (no amount of C will help you with either of those languages). Now whether this is a virtue is a completely different topic.
      I think it's important to note that while it may be possible to apply prior programming knowledge to Perl and even come up with some 'working' code without ever learning the basics, it certainly wouldn't be reasonable to advise beginners to do so. Additionally, I can't think of any case where it could be stated that someone who disregards the basics and dives head first into the code armed only with prior programming experience would be 'qualified' to write Perl. I once built and installed a kitchen counter (badly) and i wouldn't presume to be a qualified carpenter.

      When I said that 'Prior experience in programming languages may be very helpful when learning a new language' I meant the emphasis to be on 'learning'. 'Learning Perl' contrasts sharply with 'Using Perl to pound a few nails'.
Re: Five Common Misconceptions While Learning Perl
by Anonymous Monk on Dec 02, 2005 at 03:17 UTC
    but it doesn't mean you know how to properly express yourself in said new language
    Properly express =~ take advantage of the benefits
Re: Five Common Misconceptions While Learning Perl
by ghenry (Vicar) on Dec 02, 2005 at 08:12 UTC

    This should be on one of the FAQ somewhere!

    Maybe, "What are the Common Misconceptions While Learning Perl?"

    Walking the road to enlightenment... I found a penguin and a camel on the way.....
    Fancy a yourname@perl.me.uk? Just ask!!!
Re: Five Common Misconceptions While Learning Perl
by initself (Monk) on Dec 02, 2005 at 17:53 UTC
    I look forward to the day when I embody this: "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."
Re: Five Common Misconceptions While Learning Perl
by radiantmatrix (Parson) on Dec 02, 2005 at 19:23 UTC

    Most of the objections to perldoc can be solved by pointing people to perldoc.perl.org. I personally find it better than the perldoc "man pages" because it is easier to search, can be simply bookmarked, etc.

    If you're learning Perl, the same site offers an archive of itself that you can download and run locally. Truly invaluable.

    <-radiant.matrix->
    A collection of thoughts and links from the minds of geeks
    The Code that can be seen is not the true Code
    "In any sufficiently large group of people, most are idiots" - Kaa's Law
Re: Five Common Misconceptions While Learning Perl
by sub_chick (Hermit) on Dec 03, 2005 at 05:19 UTC
    For someone just starting out like me, this is definitely a breath of fresh air. All five misconceptions you have pointed out have ran through my head once or twice before and since I've began.

    "Es gibt mehr zu Leben als Bücher, kennen Sie. Aber nicht viel mehr " -(Der Smiths)
Re: Five Common Misconceptions While Learning Perl
by rir (Vicar) on Dec 10, 2005 at 07:15 UTC
    Did you google on PERL and tutorial or did you draw from hyperbole or imagination? Did you intentionally mislead us, lie to us, dupe us or was it just ineptitude?

    My inflamatory rhetoric above is only to mirror yours. When I found that google search rather different than you implied, I distrust your whole post. I suppose rather like you were soured by some of the mistakes in tutorials on the web.

    I see the first search results this way:

    1. an old (1995) intro by a Ben Johnson at the National Ctr. for Super Computing. Basic intro for people who Ben expects to read the docs.
    2. Perl4 dox with a intro stating it is just of historical interest. A sensible beginner would move on.
    3. by a John Pollock at The Web Design Resource this is both out-dated and a bit lame.
    4. is a reference to perlmonk's Tutorials.
    5. is a Carnegie Mellon University Perl4 manpage. It does have a header mentioning Perl5 and pointing the reader to perl.com.
    6. is www.perl.com. All my readings there have been worthwhile. I haven't read a beginner's tutorial there but I'm inclined to give it a pass. That is prejudice, I have no real reason to think that cause they can publish good mid- to high-level instructions that they would be good with a beginner's tutorial.
    7. is Robert's tutorial in the UK. This is outdated and dated in its own time. Rather lame. Its saving graces are that it shows -w early on and that it points the reader to perl.com and activestate.com.
    Be well,
    rir
      Despite the fact that you indicated that you wrote this 'inflamatory rhetoric' to illustrate a point rather than to be taken literally, I'd like to respond to it:

      > Did you google on PERL and tutorial or did you draw from
      Yes, I did.
      > hyperbole or imagination? Did you intentionally mislead us,
      Yes, I drew both from hyperbole and imagination, and no I didn't intentionally mislead you.
      > lie to us, dupe us or was it just ineptitude?
      or lie to you or dupe you. Yes, my attempt at using 2nd person narrative to describe the activities of fictional users was probably driven by my ineptitude at expressing myself in prose.

      I'm not sure what you're getting at with your post. By your own admission, 57% of the tutorials you've found on Google are one of (or all) outdated, 'lame', or requires the reader to be sensible. This supports my comment that 'Certainly the majority of tutorials will mislead you, lie to you, teach you broken concepts, and basically waste your time'. Note that I didn't say 'all tutorials will mislead you, lie to you, or teach you broken concepts', just the majority.

      I don't believe that when a beginner approaches a new language (especially if they have no prior programming experience) that they should be expected to be sensible about what learning material they choose or have some innate ability to guide themselves to well-written learning material. I also don't believe that if you present an outright beginner with 7 choices of material to learn a new concept from that they will somehow instinctively choose the best material. That's why I think it's a good idea to guide people to the best possible material at the outset and allow the beginner to focus on learning rather than disseminating the good from the bad.

      As a clarification, all of the 2nd person narratives at the beginning of the misconceptions are fictional and straight from my imagination. They may not hold up under intense scrutiny, nor are they meant to. They are meant as an entertaining read to describe what a random, fictional beginner possibly encountered. They aren't based on my own experiences, but are rather drawn from my imagination and from the actual experiences of literally hundreds of people I've found to have been mislead during their learning process. I apologize if this is unclear, but I guess you'll have to chalk it up to my less than adequate ability to express myself in written English language. Alluding to an ulterior motive to mislead or lie to people is uncalled for. (The previous statement is in response to 'When I found that google search rather different than you implied, I distrust your whole post.' rather than to the admitted 'inflamatory rhetoric' to 'mirror my own')

      Thanks
      m.att

        M.att, the key point of my reply was what you replied with: Alluding to an ulterior motive to mislead or lie to people is uncalled for. That is what you did, or you were more direct.

        I don't and didn't subscribe any ulterior motives to you. I did not mean to allude to such either, I only meant what I said I ... found that ... search ... different than you implied, I distrust your whole post. No allusion to motives intended: I find an error and so I doubt the accuracy of the rest of your post.

        That you feel so attacked demonstrates my point. You smeared a bunch of people who, just like you, went to some effort to share their knowledge. You impugned their competency, motives and honesty. When I only ask if you are doing the same you are offended.

        My lame does not equate to your utterly horrible and I do not agree that my examples support your point. I am not offended that someone codes to a standard I dislike: &routine is perfectly good perl. (Most Monks realize that &name cannot be routinely applied to builtins. The student who learns that convention early on also learns early to distinguish builtins from package subs.)

        I found your first post to be entertaining, you succeeded in that. I generally agree with your post.

        Beginners have misconceptions1 because they are beginners. What is good teaching material is difficult to determine without access to the student. Even the student who likes and wants to learn will coast, or stop learning, at some point. The student who learns just to accomplish some specific aim will do this at the earliest possible time. This suspension of learning can leave gaping holes for a long time. The sites I called lame may very well serve someone who just wants to achieve some aim. That they don't want to learn Perl, but just want to do XXX, does not make them less worthy of being taught. You, and I, will want to teach them Perl--someone else may be able to teach just what they want to know. The people who were so served, if any, will not be likely to come to your attention, they moved on.

        Be well,
        rir

        1 -- there are also voids of conception ~

      My Google experience was somewhat different. Entering "Perl tutorial" as a phrase, I only had 195,000 hits. I checked out the first 21 (I'd have stopped at 20, but the last page was in German so I continued to the next English-language page).

      1. More about makefiles than Perl.
      2. Not found.
      3. Outdated tutorial for Perl 4
      4. Perl 4 tutorial.
      5. Not horrible, but uses some deprecated code.
      6. Last update was in 1999
      7. Discusses Perl 5.6.0; written in 2001
      8. Dated 1999
      9. PerlMonks!
      10. Dates to 2000
      11. Dated 1999 – discusses how to work with RSS
      12. Discusses how to select the correct database
      13. Author states, “…I’m not an expert with Perl”.
      14. Gave me a blank page when I tried to access this link.
      15. Discusses Perl 5.005
      16. Referenced page did not have the word “Perl” on it; search options did not return any hits for “Perl”.
      17. Tutorial from 1995.
      18. This was a page linking to sites purporting to teach Perl; did not have any information about Perl on the page itself.
      19. Decent tutorial for someone who knows some programming. Not for the complete novice.
      20. German-language page that I cannot evaluate.
      21. Link to Perl.com!

      Almost all these links were useless, especially to a complete newbie to programming. The only ones that seemed good were the ones to PerlMonks and perl.com, and #19. Numbers 5 and 7 weren't altogether useless. Overall, only 25% of these sites appeared to be helpful. The rest were not (IMNSHO).

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://513422]
Approved by Crackers2
Front-paged by Crackers2
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (11)
As of 2014-10-01 18:44 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    What is your favourite meta-syntactic variable name?














    Results (32 votes), past polls