This is a chicken and egg question-- and there is no answer to it. There is no worry that we won't have a next generation of gurus. We even have a Monk who is quickly going from teenage whizkid into adult guru-- just plain using the regex engine in Perl wasn't good enough for japhy, so he started hacking perl source files.

At some point, any serious user of a module or language feature is going to question the module's or feature's behavior or want to do something a little different. Through the miracle of open source, they can look at what they've been using, see how it worked, perhaps improve it, perhaps decide that it looks too kludgy for comfort and gut it (see Perl 6).

But on the other hand, there are those of us who want to keep our scripting tasks manageable, and a quality module is often a key aspect of doing that. Understanding of CGI transactions is important if you are going to use CGI.pm for anything serious. But spending a lot of time writing all kinds of CGI transaction handlers from scratch is a waste of time, unless you are already well versed in CGI.pm and find that it has a fundamental design flaw that no one ever noticed before. Sure, it may be good as an introduction to CGI to have a quick session of writing simple CGIs without CGI.pm, but once you've done a few basic "hello worlds", why continue down that path, unless your intent is to be a future CGI.pm hacker?

The question of when to recommend a module isn't, IMHO, centered on the learning process, it is centered on the quality, ubiquity, and coreness of the module. Not using CGI is silly, that's like suggesting that instead of using a hash, that you build your own associative arrays out of lists (or something). Why rewrite the stuff that comes with a standard Perl install?

But a module like Tk::HTML is a different story. Is that a module you would recommend? It has no documentation, the sample code included with the module failed to compile on at least one system of mine, and it crashes on tags it doesn't understand. I wouldn't recommend it to anyone who wasn't willing to take the time to rip it apart, to understand Tk and presentation of HTML. For someone who wanted to build a Tk web-browser I might recommend LWP and HTML::Parser (or ::TokeParser) instead, since the amount of work to get to a place of understanding and functionality might be about the same. But certainly they should know about the module so they have it as a reference.

If someone doesn't want to use a core module, though, they should know why. The existence of the core module isn't going to prevent the curious from investigating or trying their own hand at something. I like to see recommendations for good modules where one exists. Obviously if all we've done is search CPAN for something that looks like it might fit, we have not done enough wrt to that question and answer.

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.