Hello,

Fun post! Thanks for starting the discussion. I asked something related not long ago that you might find to be an interesting read while some of the monks begin putting together their list. (Though I'm curious to see how many will come up with 10.) It seems to not be as easy to answer as you might think at first.

By the way, what are some of the modules YOU learned the most from? :-)

P.S. I moved your post from Seekers of Perl Wisdom to here in Meditations since this is more of a request for comments/opinions as opposed to a specific question on code, a module etc. You may want to edit your title by prefixing it with an 'RFC:' to attract more of the responses you're looking for here.

Thanks for moving this. If I had known/seen the links to related content, I wouldn't have posted this. Thanks for sharing those links.

You could do a lot worse than take a look at the IO::* modules by Graham Barr.

Of course, many of his modules have subsequently been maintained by other authors and so contain their influences also. Not always for the better.

You do know that the unit "Barr" is named after Graham, don't you? Which is the unit of measurement of misusing Perls OO system. Most programmers code will be expressed in milliBarrs, with Graham the only known coder to achieve 1 Barr.

misusing Perls OO system

Such an emotive, subjective and utterly meaningless criteria to apply a metric to.

He wrote (writes?) practical, pragmatic, relatively efficient, well-structured modules, with well thought out interfaces that work, across many platforms, and continue to work a decade or so later.

And those things are far more important to me, and to the thousands of general users of his modules, than any airey-fairy, nancy-wancy theoretical 'not-good-OO' or academic O'Woe critiques.

By all means, be the one(*) to re-write IO::Handle or IO::Socket::* using the latest greatest OO framework. And when you're done 3 years from now and you have a mess of OO-spagetti, it'll be 10x as big, take 20x as long to load and run half as fast. And no-one will use it.

The difference between good and bad OO is not whether it performs all internal attribute accesses through setters and getters in order to more easily accommodate the wholesale change of the internal data representation that will never happen. It is: is the interface clean; and: does it work in an efficient manner.

The whole point of abstraction is to hide the difficult stuff behind simple, clean interfaces. So that the module writer can use his knowledge and expertise to best effect, and the user can benefit from that expertise without having to become an expert.

Barr's module do exactly that.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

++ for making me laugh.

--Dave

Before you decide on what module to pick, picking a learning target is way more important. Where do you want to improve?

• OO programming (Moose)
• XS programming (DBI, Tk, Text::CSV_XS)
• GUI programming (Wx, Prima)
• (De)parsing (HTML::TreeBuilder, XML::Parser)
• ...

Note that some good modules (like DBI) will prefer performance and efficiency over clarity and maintainability. Also note that module age might show its traces. Patches most often do not make the code clearer or more understandable: they more fix bugs. Also if a module changed maintainership, code might get harder to read as different styles mix (unless the new maintainer alter the style of all the module parts). Having modules with many authors might even get more confusing.

update: many of above mentioned modules cover more than one area, as noted below, like XS + Parsing or OO + Documentation. Main thing still is to pick the module that stands out in the area you want to improve on.

I pick DBI for improving interface documentation!

I've worked with a lot of structured programmers, and as much as they dislike working with my OO code, they never seem to have a problem using DBI. Part of that is probably inertia...everyone uses it, that's just what you do. But I also think DBI's documentation has a lot to do with it.

Learn to write code people don't have to read to use. As for modules to read the source to learn from, sorry, not much in the way of ideas there.

--Dave

I've worked with a lot of structured programmers, and as much as they dislike working with my OO code, they never seem to have a problem using DBI.

On the other hand I see plenty of DBI-related questions on perlmonks and other perl-related discussion media. Lots of people seem to have problems with DBI (as with any other frequently used module)

Though to be fair, many of the posters apparently haven't read the documentation, or don't understand English well enough to grok the documentation.

Perl 6 - second systems done right

I agree with Tux that the modules you pick depend on what you're trying to learn. We will also have different categorizations of the modules. For example, Tux chose Wx as an example of GUI programming, but to me that is a good example of XS programming with C++ ! It's a good idea, to think of what different modules can teach you.

Great way to learn specialized Perl.
perl.j-----A Newbie To Perl

I recently did some work on an Excel TDD harness (here), and I found it very useful to take some code that was not well documented and write documentation for it, both technical and user. I have often heard that documentation is better when written by someone other than the original programmer, and there are comments in this thread about how poor some of the documentation is. By following this approach, a number of benefits are available, if the module is being maintained. First and most obviously, the community benefits from the documentation. Second, if I were the author of anything on CPAN, I would respond much more favourably to someone who wrote "I'm trying to improve the documentation. Have I understood this properly?" (especially if shown draft documentation) than to "I'm a beginner and don't understand". Third, the code is getting a review that might identify bugs. Even if they aren't fixed, it is useful to have them documented.

Regards,

John Davies

++!

As a side note, I notice that the more complicated my modules are/get, the better my documentation gets, because I have to read the documentation myself to know how to use what I wrote myself. Yes, a system can get complicated or expressive enough for even the author not to use all edge cases.

Especially when you write/wrote a feature to please someone else, and never saw a (good) use-case yourself, a day may come you think "didn't I implement something like this already?" and then you read your own docs. Proceless!


Enjoy, Have FUN! H.Merijn

Well, I certainly used to code that way, but not in the past five years or so. Because I also learned that real men who don't use strict also spend all their time fixing bugs.

If you are going to read my modules with the aim of improving your skills, I'd suggest sticking to my recent efforts, such as:

• Regexp::Grammars
• IO::Prompter
• Contextual::Return
• Lingua::EN::Inflect
• List::Maker
• Data::Show
• IO::Interactive

If you do decide to read some of my other modules, especially the older ones, treat them as parables (i.e. as cautionary tales—mostly of woe—teaching sombre and sobering lessons by tragic counter-example ;-).

Damian