Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"

Keeping sharp and fresh

by aufflick (Deacon)
on Sep 22, 2005 at 01:58 UTC ( #494009=perlmeditation: print w/replies, xml ) Need Help??

We can all get bogged down in the way "we" do things, or the way our project or team uses modules, objects etc.

Perl is so rich that very few of us appreciate all the productive uses of all of Perl's features, especially outside the problem domains in which we are comfortable.

With the demise of The Perl Journal (long live The Perl Journal!) and the way that other mags are stuffed with Java, Python and even Ruby (which I admit to quite liking) it's not obvious how to stay fresh.

Obviously reading and occasionally wading into PerlMonk discussions is one useful tool to keep one's mind open.

Another I do from time to time is to run through some random quesions in's Perl Test.

What do other people do to hone their Perl skills and their knowledge of useful CPAN modules?

Replies are listed 'Best First'.
Re: Keeping sharp and fresh
by itub (Priest) on Sep 22, 2005 at 02:12 UTC
    The Perl Journal still existed last time I checked (a couple of weeks ago), although some say that it's not the same as in the old times...

    The Perl Review is another publication that I recommend. often publishes interesting articles, and it's free.

    A good way of honing your CPAN skills is to watch the recent uploads, read the documentation for modules that sound interesting, and play with them.

      I find it amusing that the Google adwords system thinks that one of the two relevant ad's to place on The Perl Review home page is "What is COBOL?" :)

      The Perl Review does look good - reminds me of the old paper issues of TPJ.

      I notice an article on Logic programming by Ovid

Re: Keeping sharp and fresh
by Zaxo (Archbishop) on Sep 22, 2005 at 03:15 UTC

    I like to ward off my natural dull stale bluntitude by poking around in the odd corners of perl to see what slithers out. Trying experimental features is one easy source of that. I think most programmers agree that the best way to learn Perl - or any language - is to write some and see what breaks.

    That was how I stumbled into writing Tie::Constrained. I was playing with the experimental :lvalue subs, and noticed claims that validation was impossible with them. Taking that as a challenge, a little thought persuaded me that validation needed to be wedged into assignment. The only way I found to do that was with a tie'd variable. The demonstration I wrote had a simple tied class module that proved to be a really versatile way of handling dynamic typing, among other things. It has nothing to do with lvalue subs anymore, but I would have never written it without my pushing at the edges of perl.

    For CPAN module info, I do frequent i /foo/ queries in the CPAN shell for any term, library, or acronym which has caught my attention. The CPAN shell readme is a good first indicator of quality, and if it looks interesting I'll get the module and check the source.

    After Compline,

Re: Keeping sharp and fresh
by spiritway (Vicar) on Sep 22, 2005 at 06:33 UTC

    Sometimes I "reinvent the wheel" - write something that already exists. The idea isn't to make a better wheel, but simply to learn how to make one - and in so doing, learn some new tools.

      Good answer!  I completely agree that a lot can be said for "reinventing the wheel"!

      In addition to "learning how to make one" and "learning some new tools":

      1. Often, you need a special wheel that best fits your particular needs.
      2. There's the possibility that you'll stumble onto a better/faster way to make "one"
      3. You'll learn the tradeoffs involved in making "one"
      4. There may be common mistakes associated with the particular "wheel" you're (re)inventing, so overcoming these mistakes will make you a better programmer
      5. If you've reinvented it several times (or several dozen times), it may take you only a moment to create it in a future program.
      6. You get just as much experience writing something that already exists as you do writing something new.
      7. After you write it yourself, you can go evaluate the one that already exists (probably at cpan), and see how you did!
      Think what the consequences would have been back in 1987 if Larry Wall hadn't "reinvented the wheel" when he wanted something more powerful than sed, awk and sh to program in!
        I haven't thought of focussing on this - when I have tried, I inevitably end up realising why the module author took so many lines of code to do it when I thought it was simple! In that way it can also teach respect :)
Re: Keeping sharp and fresh
by monarch (Priest) on Sep 22, 2005 at 03:23 UTC
    As with anything that consists of so many nuances it takes effort to move out of a comfort zone. That may be, as suggested, by wading into discussion forums, reading new CPAN modules, or merely debugging code.

    I find discussion with team members, and members outside my direct team, can provide valuable insight to the way I do things; code reviews are excellent for this, as one cannot learn without the humility of being subject to criticism.

    Just this week I've learnt some excellent techniques for greatly speeding up raw text processing and this has been through listening to others; and to them I give the credit of the speed increases..

Re: Keeping sharp and fresh
by cbrandtbuffalo (Deacon) on Sep 22, 2005 at 12:01 UTC
    Couple more options:

    * Find a local Perl Mongers Group and drop by for a few meetings. You can even offer to give a presentation on some new module--there is no better way to learn something than to teach it.

    * Automate some things in your digital life. Look at anything you do repeatedly and try to write a Perl script to do it for you. Then use all the free time you've found to repeat this with something more complicated.

Re: Keeping sharp and fresh
by pg (Canon) on Sep 22, 2005 at 02:40 UTC
    "very few of us appreciate all the productive uses of all of Perl's features, especially outside the problem domains in which we are comfortable."

    The fact is that nobody will really wonder into every corner of Perl, or any other language. For languages like Perl, Java or Ruby, which tend to have specific modules to cover lots of specific function areas, you never have the need to cover all of them, although you might occassionally open up couple of modules to see how other people do things.

    Not only those specific modules, even with the basic functionalities, there is never a need to use all of them. Not only that you don't need them, you actually should intentionally avoid some of them. Almost all languages, more or less, have some functionalities that do more harm than good. It is more important to learn best practices and stick to them, than to utilize the full language.

    "What do other people do to hone their Perl skills"

    Lots of practice with the best practice in your mind.

Re: Keeping sharp and fresh
by dragonchild (Archbishop) on Sep 22, 2005 at 12:48 UTC
    It is less important to stay sharp in Perl in specific as it is to stay sharp in the arts of programming in general. For example, I've been exploring TDD over the past year and it's been making some fundamental changes to my programming style and expectations. TDD is applicable in any language, and I've been applying it to both Perl and JavaScript.

    In the specifically Perl camp, I like reading TheDamian's code. His style stretches my understanding, whcih is the point, right?

    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
        Test-Driven Development. It's a practice that was made popular by XP (eXtreme Programming). The theory goes something like this:
        1. Start with no code and no tests.
        2. Write a test.
        3. Run that test and see it fail. (Remember, you have no code, yet.)
        4. Write the absolute minimum amount of code to pass the test.
        5. Run that test and see it pass.
        6. Check it into source control
        7. Goto #2

        At all times, your entire test suite should always pass, except for the one test that you're currently failing because that's the one specific piece of the spec that you're currently implementing. Whatever is in source control should always pass all the tests. Theoretically, you have 100% code coverage (as reported by Devel::Cover) because you never wrote a piece of code without having written the test for it first.

        My criteria for good software:
        1. Does it work?
        2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
Re: Keeping sharp and fresh
by kwaping (Priest) on Sep 23, 2005 at 15:01 UTC
    I don't mean to sound brown-nosey, but being active on PM does it for me. I find that posting answers (and the occasional question) does a lot more for me than just reading, for all you lurkers out there.

    I also love to code golf. I've picked up some great tips and techniques on PM for that, too!
Re: Keeping sharp and fresh
by Anonymous Monk on Sep 26, 2005 at 17:28 UTC

    One thing that works well for me is to hit at least a few times each week.

    If I see an interesting new module or an update to an old module I go read up on it.

    This is also a great way to keep an "ear to the ground" for new ideas moving through the Perl community - since so much of Perl's best ends up on CPAN anyway.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://494009]
Approved by QM
Front-paged by Old_Gray_Bear
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others having an uproarious good time at the Monastery: (4)
As of 2023-12-10 13:46 GMT
Find Nodes?
    Voting Booth?
    What's your preferred 'use VERSION' for new CPAN modules in 2023?

    Results (40 votes). Check out past polls.