Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister

Perl Exercises

by jesuashok (Curate)
on May 18, 2006 at 04:41 UTC ( #550154=perlquestion: print w/replies, xml ) Need Help??

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

This node falls below the community's threshold of quality. You may see it by logging in.

Replies are listed 'Best First'.
Re: Perl Exercises
by TedPride (Priest) on May 18, 2006 at 08:33 UTC
    Not to ask stupid questions, but if you're leading a "Perl Team", shouldn't you be coming up with the exercises yourself? A quick read through the last couple weeks' worth of posts to Seekers of Perl Wisdom will give you many ideas. Also, what's with the "Each exercise should take at least one day of time to finish"? The whole point of Perl is that it's the fastest language on Earth to write programs in, so assuming you do your job well, the exercises shouldn't take more than an hour or two each for your students to complete. I suggest lots of tiny exercises for references, nested data structures, and regular expressions, with a brief skimming over of the other topics. Nested data structures are probably the most difficult thing to understand as a newbie programmer.
Re: Perl Exercises
by GrandFather (Saint) on May 18, 2006 at 10:10 UTC

    Code writing exercises are all very well, but something that is often neglected are debugging exercises. Start with code that exhibits various bugs and have your team find and fix the bugs.

    A valuable lesson along those lines is to present some code without strictures that is to be debugged. Bugs involving incorrect reference usage are particuarly good for this. If they don't figure out to add strictures for themselves, after they have struggled for a while add use strict; use warnings; and show them how to catch many types of error without even running the code.

    In the same sort of sense, reinventing wheels can often be good exercise. For example: CSV data is nasty stuff to parse. You could write a number of CSV data sets of varying nastiness and have your team write code to parse the data. Present the data sets in order of nastiness to see if you can break each itteration of the code. At the end of the day present a solution using one of the CSV modules to show why reinventing the wheel is a bad idea!

    DWIM is Perl's answer to Gödel
      GrandFather, I totally agree with you. I am new to Perl and I have learned so much just looking at existing code and trying to find out what they did and often times I do find "bugs". My next challenge is to learn how to fix them. It has really given me a good grasp of Perl and what I can do or not do in my own code.
      I have also learned a lot from reading SOPW entries to see what others have had problems with and how these were solved.
      I love this site!
Re: Perl Exercises
by idle (Friar) on May 18, 2006 at 07:42 UTC
    Have you seen Llama book? It contains several chapters with good exercises at the end of each.
      I have the Llama book. The exercises are fine but there aren't enough on one thing. If I found the concept of traversing hashes difficult, I would like to do more exercises on that. Don't get me wrong the Llama book is a great start, but I think other resources are necessary.
Re: Perl Exercises
by Herkum (Parson) on May 18, 2006 at 12:55 UTC

    If you are going to mention bugs, why not focus on writing tests? It is amazing to me that this area is so broadly ignored by programmers. An even better place to start would be writing modules that would follow the format of a CPAN distribution. Requiring a,

    • README file, force them to write notes about anything special about module.
    • Changes file, force them to keep track of their changes to their code.
    • Build.PL file, gets them thinking of their code as a building block that other programs/modules can use.
    • a t directory with a standard set of tests (like Pod and Pod-Coverage). It is easier to write tests if they know where those tests will be and what can be expected.

    The tests get them into the good practice of writing interfaces for their code instead of writing code and then try to figure out how the interface works. It gives them examples of how to write code in general.

    To often I see programmers write modules without any documentation, working examples, testings or ANYTHING THAT IS NOT CODE! It leads to crappy, buggy and ultimately unmaintainable code.

    Why? Reading code is hard, when code be explained in english in a few sentences and be read in a minute might take 10 or 20 minutes of reading code to figure out how it is supposed to work. The reason for this is code has no frame of reference, writing documentation is supposed to do that.

Re: Perl Exercises
by blazar (Canon) on May 18, 2006 at 09:50 UTC
    NOTE: Each Exercise should take atleast one day of time to finish.

    Gawd! I would hardly call an exercise that "takes at least one day to finish" an exercise any more. I would call it a complete program/project/framework, etc.

Re: Perl Exercises
by ptum (Priest) on May 18, 2006 at 16:00 UTC

    If you are "leading a perl Team of 7 members", why do you need to test their knowledge? Seems like you would do better to teach first (if you have the ability yourself) than test them on something they don't yet really grasp.

    When I first began to use Perl, I received some minimal formal instruction and then was almost immediately responsible for the oversight of the work of 8 or 9 other developers. Rather than try to emphasize the gulf between my 'knowledge' and that of the rest of the team, I organized a weekly code review and seminar in which I encouraged others to teach what they had learned over the course of the week. While I still did much of the teaching, I found that many of the developers grew rapidly in their enthusiasm and understanding of Perl as they were permitted to learn through teaching. Sometimes I had to gently correct, and sometimes we all rushed off doing the wrong things in the wrong way (with my ignorance compounding theirs). We grew closer as a team and I learned a lot along the way.

    I don't think there is any substitute for learning while doing real work. Why not divide your next project into manageable chunks and parcel it out to your team members? If you spend some serious time on code reviews (and adopt some of the write-to-test advice you received from Herkum) you'll make good progress on your project and teach as you go.

    No good deed goes unpunished. -- (attributed to) Oscar Wilde
Re: Perl Exercises
by Anonymous Monk on May 20, 2006 at 12:07 UTC

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://550154]
Approved by GrandFather
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (3)
As of 2022-08-19 04:15 GMT
Find Nodes?
    Voting Booth?

    No recent polls found