http://qs321.pair.com?node_id=262581

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

Fellow monks,

In the final chapter of his book Beginning Perl (my review of which is here), Simon Cozens writes the following:

"...the modules and programs in CPAN are worth reading as examples of Perl code. Look at how Perl programmers view problems and furthermore, how they solve them. Examine the way they structure their programs, and get familar with the idioms they use. The way to get really fluent in a language is to pick up on what the natives do and copy them."
Sounds great in theory, but with more than 4,000 modules on CPAN, where on earth does one start? Or, to put it another way, which modules would the monks recommend as examples of good coding that someone like myself, who just hacks Perl as a fun hobby but who is keen to improve his skills, can learn from? And are there any that are good examples of how not to do things? TIA, mooseboy

Replies are listed 'Best First'.
Re: Learning from modules
by gmax (Abbot) on Jun 03, 2003 at 07:41 UTC

    I wonder why you would like to follow the advice of a book you DON'T recommend, :) but anyway, learning from good code is not a bad idea.

    You may start with the most famous modules. If they seem to be too hard for you - especially if they are big - then look for their author on CPAN, pick a smaller module that they have written and study it thoroughly. Then, come back to the big one.

    You may continue with a Super Search in the Monastery. Look for "RFC" in titles and CPAN in the text. This way you'll see what the Monks are proposing to publish on CPAN. You won't get everything, but OTOH you don't have time to read everything, so it should be a good start.

    My personal advice is to start with the modules that, in addition to good code, have also good documentation, without which any good code will soon fade into oblivion.
    See Looking for Mr. Good Documentation! for some hints on well documented modules.

    _ _ _ _ (_|| | |(_|>< _|
Re: Learning from modules
by Juerd (Abbot) on Jun 03, 2003 at 07:36 UTC

    where on earth does one start?

    The modules that you already are familiar with. Examine how they do what you have come to expect from them. Or pick a Perl Monk, see if they have a CPAN ID and have a look at that Monk's modules. Or visit some list of people's favourite modules.

    IMO, CGI.pm is a good example of how not to do things. Do use strict, do separate, do not let any source file grow as large, do use sane (small) export tags, do not provide system wide configuration and do keep documentation simple and to the point (again: do separate: move tutorials to their own documents).

    Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

Re: Learning from modules
by gjb (Vicar) on Jun 03, 2003 at 07:31 UTC

    I'd look at those modules that interest me, either because I use them a lot, or because I'd have ideas about implementing similar functionality myself. Since going through someone else's code is not always obvious, extra motivation is important ;-)

    A very important criterion is the author, you can get clues on "good" authors by hanging around on Perlmonks and reading posts by various people. Many nice posts are written by people who happen to have authored useful/well written modules as well. I'm not going to name anyone, just see for yourself.

    Just my 2 cents, -gjb-

Re: Learning from modules
by Zaxo (Archbishop) on Jun 03, 2003 at 08:43 UTC

    I'd start with some of the ones distributed with perl. You already have them, and they get the closest scrutiny and the most testing.

    On CPAN, for non-core modules, try choosing modules whose use and purpose you understand well. If you want to be careful at first, also choose authors who are known for the quality of their work.

    For advanced credit, study the opus of DCONWAY . :-))

    After Compline,
    Zaxo

      For advanced credit, study the opus of DCONWAY.

      Funny you should mention that, I've just started reading his Object Oriented Perl. My head is spinning already and I'm only about half-way through chapter three! %-)

        Stick with it though as it's really a great book and you will learn much OO hackery as a result :-)

        -- vek --
      they get the closest scrutiny and the most testing.

      Funny guy! Several of the core modules have no maintainers, have had no maintainers for years, and have apparently had no one read the documentation, update the code, or do any sort of testing at all for years. There's a lot of ugly code in the core and a lot more cruft.

      For one example, see ExtUtils::MakeMaker. Yuck. It predates File::Spec. On the other hand, less is completely tested, well-documented, and easy to read.

Re: Learning from modules
by ViceRaid (Chaplain) on Jun 03, 2003 at 12:33 UTC

    I think it might be worth trying to figure out what you'd like to learn, as that might help point you in the right direction. The quotation from the book rightly point that there's lots of wisdom to be learnt from the core modules and others on CPAN. Let's assume a somewhat false distinction between learning about problem solving in Perl, idioms and good manners.

    "Look at how Perl Programmers view problems and furthermore, how they solve them"

    If you're keen to figure out (generally) how to do (specific) things in Perl, find a CPAN module that does something that you know about from elsewhere, as other posters have suggested. For example, let's say you've got an interest in Linguistics: take a look at the Lingua family of modules, which do clever things with natural language. Or if you're hot on HTML, take a look at the HTML family. Then you can see how a problem whose parameters you understand well (let's say, cleaning up HTML) can be solved using the specific tools and resources which Perl kindly offers you.

    "Examine the way they structure their programs"

    It's nice to be nice, to yourself and other people. There's lots of conventions about writing perl, from the syntax to the structuring of a module's files that will help you avoid heartache. I guess here, you might want to follow Zaxo's advice, and look for CPAN modules by authors of good repute. For example, you could find out how to use packages to stop variables from different bits of a program bumping into each other.

    "get familar with the idioms they use"

    You might like to know how to use some less obvious features of Perl to do specific things concisely. For example, suppose you wanted to store some English text for use in your program, but didn't want to have to constantly have to move another file around with your Perl program:

    my $text; { local $/; $text = <DATA>; } ... rest of your program here __DATA__ foo bar bla bla foo bar

    I think of this as something that's useful, concise, but not immediately obvious from the bare syntax and functions of Perl. If this is what you're after, again, take a look at widely-used modules by well-known authors, or (some) of the core modules, but...

    I suppose I'd be a bit wary of just picking a random core module and looking at it for ideas, even though, as other monks have pointed out, they're very well tested. After 5 years, I still find some of the core modules a bit intimidating, as you'd expect from modules written by super-experts. Furthermore, some of them depend on C-extensions, so though you might learn something about writing nice, polite interfaces, you can't learn much about algorithms or idioms. Finally, lots of them deal with problems and deep internals you probably won't ever have to worry about, because somebody else already has, as evidenced by the fact that module exists and is in core. There are some exceptions - for example, the Net family, which are very useful, especially if you're interested in that sort of thing anyway.

    Happy browsing

Re: Learning from modules
by chaoticset (Chaplain) on Jun 04, 2003 at 15:13 UTC


    Easy -- even though it's not Presentmas currently, you can start with The Perl Advent Calendar. Plenty of snifty stuff on there.

    I am questioning the wisdom of starting with CPAN, though. Lots of these modules are idiom-heavy, and idioms (in my experience) are hard on the beginner. Necessary, yes, but hard.

    If you're going the learn-from-CPAN route, consider taking a single chunk of code at a time, un-idiomizing it, and finding out why it's that way. It's not that it isn't fascinating code, and it's not that it's not good code -- it's just pretty advanced.

    -----------------------
    You are what you think.

Re: Learning from modules
by theAcolyte (Pilgrim) on Jun 03, 2003 at 20:53 UTC
    Wow. I think this is a truly horrible idea.

    I did exactly this as a perl newbie, an idea of my own, and looking at the code in CPAN modules simply made my head hurt. If you don't already have -lots- of experience is some programming langage, then looking at good CPAN code is most likely to confuse you.

    Hell, I've written major web-based applications for paying clients and some of the code in some modules still throws me for a loop

    The best way to learn is to start small, learn the fundammentals and build up. When you're ready you'll know it, then you can tear apart heavy duty modules and figure out what makes them tick

    If you want to learn to build an engine, you don't start by taking apart the nearest helecoptor motor. You start with that little one that powers your remote control airplane.

    # Erik

      Thanks to all monks for the suggestions ... plenty of food for thought here. After all, what better way to spend the summer than poking around in the darkest depths of @INC? ;-)