Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Perl Skills

by Anonymous Monk
on Jun 14, 2010 at 18:06 UTC ( #844690=perlquestion: print w/replies, xml ) Need Help??

Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

I am making an serious attempt to learn more Perl. So with limited time (read few weeks) at my hands, I am thinking which one are considered good skills to have. I am thinking of making myself familiar with Perldoc, Knowing basic core modules and important cpan modules, regex, perlcritic, domain specific modules, Knowing web frameworks, XML processing etc.. Technically one can say 'all of the above' plus more. I like to see your take on this issue. Thanks.

Replies are listed 'Best First'.
Re: Perl Skills
by moritz (Cardinal) on Jun 14, 2010 at 18:13 UTC

    You probably have a reason to learn perl, like wanting to start or participate in a project.

    If that's the case, the best you can do is to learn a few basics, and then start coding on a similar project. You'll find that with some basic knowledge, you can get quite far. Whenever some of your solutions seem clumsy, research better approaches (but refrain from re-doing everything when you learned about a better approach).

    What helped me greatly is hanging out here on perlmonks. By reading typical, real-world problems and there solutions you can learn much about programming and Perl.

    Perl 6 - links to (nearly) everything that is Perl 6.
      My reason is future job success. So, no. I don't have any specific project for learning. Also I want to decouple project and the Perl parts. So, I don't get lost in the intrinsic details of the project or project requirement. I want to sharpen the saw.

      I often read Perlmonks posts and the solutions which helps in variety of way. I want to dive little deeper.

      While I like trial-error approach, I like to improve/deepen my fundamentals too.

        Then here are a few, more specific suggestions:

        You didn't mention object orientation. If you're not yet familiar with the Perl OO model, it would be a good idea to learn about it (like perlobj, and Moose for an extension).

        "Mastering Regular Expressions" by Jeffrey Friedl is the book about regexes, and a must-read if you want to dive deeper in that subject.

        overload surprised me with its many possibilities, and lead me to explore Scalar::Util (if you want to weed out duplicate objects, you need refaddr...)

        Other things docs you might skim or read: UNIVERSAL, perllexwarn, perlrun (it never ceases to amaze me how much you can do with perl's command line interface), perlmod for symbol tables, perlfaq1 .. perlfaq9.

        Perl 6 - links to (nearly) everything that is Perl 6.

        Don't knock trial and error. Think of it as practice. Consider learning a new human language (or your native one for that matter). You can listen to tapes and be able to call for taxis or order food in a restaurant, but you can't have any real conversations until you have some real conversations. You learn by practice because the things you read about won't really make sense until you rewrite some neural pathways by using the things you learn. If you're not knocking your head against the keyboard, you're not really trying.

        Pick a project. Anything. Create a file-find utility (using File::Find) for your hard drive. Maybe index your drive. Download movie listings (WWW::Yahoo::Movies). TV Listings (figure out how to parse Yahoo TV listings -- it can be done!). Make a DVD library, including categories so you can print out a categorized list. Don't just read PerlMonks, but actually get in there and try to solve someone's problem. THEN, LATER, compare notes with what others wrote. It doesn't matter what it is, as long as you're coding. After all, if you just want to read for future success, you'll get weeded out in the first interview. Employers will ask what you've done, not what you've read.

        That said, once you have some notion of how you'd like to sharpen your skills, search for things on CPAN. There is an absolutely immense number of modules written by others and uploaded. While the quality varies, all of the best modules (including all the core modules) are there. You can use them to get complicated things done, or you can check out the code. Sometimes, just the titles and/or descriptions will get you thinking about something you'd like to write yourself.

        My two cents. --marmot

      I have a few strategies for speeding up my understanding of a programming language, in the case of Perl I tend to:

      • implement basic algorithms that I understand in other programming languages (programming contests, puzzles are pretty good if you are in that frame of mind and have the time)
      • dig around test suites and seek out well written unit tests that test functionality I understand
      • don't skimp on taking the time to optimize your dev environment, code completion in emacs, running things automatically, etc ... becoming more efficient means you spend more time learning
      • browse the source code on CPAN

      When learning a language it can help to associate yourself with better programmers, PerlMonks is a good place to start but you may want to find an Open Source Perl project and help out ... you will learn from the core developers on the project

      Note that trial and error can be useful sometimes for getting 'muscle memory', but try to avoid too much 'hunt and peck' style of learning and never underestimate the value of instruction from others who know more.

        I think this is great advice and especially-

        dig around test suites and seek out well written unit tests that test functionality I understand

        Tests are often much better documentation of code for a developer than the Pod because, if well-done, they explore expectations, failure, and bounds tersely and much better than the average dev when trying to describe an API in plain English/Locale.

Re: Perl Skills
by almut (Canon) on Jun 14, 2010 at 19:43 UTC

    In addition to what the others have recommended, I'd say don't forget to develop your general problem solving heuristics and debugging skills (a large part of programming is debugging...).  In my experience, people not being helpless when something refuses to work is at least as important in the real world as knowing module X or software paradigm Y...

Re: Perl Skills
by duff (Parson) on Jun 14, 2010 at 18:47 UTC

    Seems like you're headed in a good direction. As far as "important CPAN modules" and "web frameworks" go, you should look at Moose and Class::MOP and Catalyst.

      But before you do that, get yourself first acquainted with the underlying basics such as DBI, the theory behind OOP in Perl, and CGI.

      CountZero

      A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

Re: Perl Skills
by hesco (Deacon) on Jun 15, 2010 at 05:40 UTC
    At the risk of adding to an already ambitious syllabus, may I suggest that you create a simple module which fills some personal need and build a test suite providing 100% coverage of your code base. I found that a very useful exercise in many ways.

    -- Hugh

    P.S.

    In response to Moritz, yes, achieving 100% coverage is not always possible -- even when I invest the time and energy, but the quest for that goal has proven very educational for me. And it has never hurt my code base to have better coverage.

    if( $lal && $lol ) { $life++; }
    if( $insurance->rationing() ) { $people->die(); }
      100% coverage isn't always achievable.

      For example I put Carp::confess statements in some of my modules to catch internal errors. When my module works fine, there is simply no way to trigger them. They are dead code.

      Still they are very useful, because when I change something and break the module, I get much better error messages than without those statements.

      One could try to trigger thee cases by monkey-patching the module to misbehave, but I think that's a rather foolish idea.

        Our way to reach 100% coverage is the following:

        1. we do module-test to cover as near as 100% as possible
        2. if we reach less than 100% (this is the normal case), we analyze/review all parts that were not covered by the test
          • if we discover testing-gaps, we enhance the module test
          • if some code is really not testable, but OK according the analysis/review, we consider it covered
        With that proceeding it is always possible to reach the 100% coverage. And I don't think it is cheating ;-)

        HTH, Rata

Re: Perl Skills
by biohisham (Priest) on Jun 16, 2010 at 19:16 UTC
    Congrats, best of luck, I do believe however that what comes quickly would go quickly, so have a short term strategy and aim for a bigger goal in the long run too, like maybe you can start to quickly bag up all the important basic pillars for the language and then solidification of the knowledge you thus reaped becomes an accumulated function of time.. The Monastery is the best place to inspect for real life problems and interactivity of different approaches of different weights to tackling a given issue at hand.

    Since you have few weeks at hand and it is not immediately clear how your current programming competency level is, a general advice would be to focus on distributing the following concepts on the weeks you have...

    • Essential Perl (Overview), scalar variables, lists, arrays, hashes.
    • Operators and Precedence, Conditionals and Looping statements.
    • Regular Expressions.
    • Subroutines.
    • Formats and String Handling.
    After having felt pretty comfortable around this part go the extra mile and hit the following, which more or less require good understanding of the above areas....
    • References.
    • File handling.
    • Data structures.
    • OOP (Packages and Modules).
    • Standard core modules and Modules installation.
    While this is not a strict roadmap but from here forward you can pick more advanced topics relatively easier and quicker...

    The best place for Perl documentation is http://perldoc.perl.org/index.html, since it has FAQs, Tutorials, as well as documentations for various modules too all in one central place...

    Best of luck and remember practice makes perfect and keep hanging around the monastery...


    Excellence is an Endeavor of Persistence. A Year-Old Monk :D .
      You mentioned "Formats" here. Just wondering is Formats still being used these days? Is it really useful at all? Thanks,
        Formats can be useful, why not? String handling requires presentation, there are many ways you can carry that out, with Formats being one of them. There's nothing that indicates that this is obsolete in anyway, check http://perldoc.perl.org/search.html?q=formats. Perl's fame stems from its string handling capabilities...

        Formats are still useful and I believe at one point or the other down your career you might need to require to use any of the formatting interfaces that Perl has...

        I use it. I have to analyze a lot of data, and I have a few programs that can give me an overview quickly. Formats make quick work of it.

        --marmot

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (5)
As of 2021-10-19 21:52 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    My first memorable Perl project was:







    Results (77 votes). Check out past polls.

    Notices?