I was reading
this post about date handling by
Friar Leon and shook my head sadly.
It amazed me that someone like Friar Leon, who has clearly
been around the block in Perldom, could not realize that
there's a Posix.pm module. (And I certainly don't mean to
pick on Friar Leon. His node was just the one that caused this
train of thought.)

My premise: We somehow need to get into the heads of the
Perl Populace that the CPAN IS YOUR FRIEND. Over on the perl6-*
lists, there's much discussion about how to handle CPAN
in Perl 6, and to promote its use.

Addendum: I'm not suggesting that a CPAN
module is the only/best way to do something. What I'm
asking is how we can make people more aware of CPAN, so
that there's less of the "Oh my gosh, that does exactly
what I spent the last N hours working on" syndrome.

maybe he just wanted to share his code with us, regardless whether this had been CPAN'ed already

some people might not have axx to the CPAN repository (not many but i'm sure they're around), or don't know it exists

reinventing the wheel is unproductive for the company/project , but then again not all wheels are perfectly round and thus can use some re-engineering. The learning process while reinventing is valuable too !

Read his reply, where he says
"Thanks ... this would have saved me quite some time ..."

I'm not picking on him. I'm not saying he's a bad person.
There's really no need for you to defend him.
I'm trying to find a way for us as a community to help
promote the CPAN so that cases like this, where someone
reinvents the wheel but didn't want to, are minimized.

some people might not have axx to the CPAN repository
(not many but i'm sure they're around),
or don't know it exists

Aha! The very point I'm trying to make.

Perhaps next time you'll want to read what's been written
before wasting time with irrelevant and incorrect hypotheses.

You're basicly right.
But just don't hit people too hard
(I'm not saying you did)
If they're not aware of some less knowns/obscure modules, or
miss them during their search or avoid them for whatever reason(limited shell, VERY simple solution needed...)

I think CPAN is just one of the numerous way to do it
(and often the best) but just let people choose (or simply be ignorant...)

There already is a corollary to TMTOWTDI in this sense; it's the First Virtue of Programming. Laziness means expending a little energy at the outset to save a lot of work later on. I think the camel book does a good job discussing how laziness can be useful, I think it even discusses CPAN in that section. But "get thee to CPAN" isn't going to help in this case.

Here's a challenge: using CPAN, try to find an indication that posix.pm is the right module to solve the problem leons did with his subroutine, without specifying strftime in the search box. I couldn't do it. The closest I came on CPAN was a reference to Date::Calc, on a search for 'date' and 'sprintf'.

If I cheated and used a google search restricted to perldoc.com, the same query gives me Date::Calc as the first choice, and a Tk:: module that mentions strftime as the second choice (if I'm willing to dig for it).

I suspect it is often less work to reinvent the wheel.

To reframe the question: how can we make CPAN more helpful to lazy people?

Here's one possible solution: CPAN should contain a copy of all module documentation in a format that google will index-- all the pod files for every module. Right now I think a lot of the documentation is locked up in .gz files.

Perhaps then, when I do a web search for "perl date sprintf" CPAN will show up in the first 40 results.
I suspect that would go a long way toward making people aware of CPAN.

Interesting. I hadn't thought of that angle. I'd always
assumed that people don't check the CPAN, and your postulate
seems to be that CPAN isn't comprehensive enough in its
searching capabilities. I know I've had problems with
search.cpan.org before, where things
that I would have expected to find were not found.

I'm concerned about just pushing the laziness angle. Lord
knows there are enough negative-scored posts here in the
monastery that say things like "How do I write a game
in Perl?".

Who remembers years ago in comp.lang.perl.misc
when
tchrist posted his rants
about the nice beach that was
overrun by people who didn't want to make the beach nice,
and only wanted to take? While I certainly take issue with
how he expressed his views, I agree with most of his points.
There's a wealth of information in the community, but
posting blindly "Hey, do my homework" isn't going to help
anyone.

So let me rephrase a different way: How can we as the Perl
Community help others to help themselves?

I realize that if you search for a specific module in the monastery, you can often find some discussion of it or maybe even a tutorial. Perhaps, we could organize these tutorials and module reviews into a specific area (perhaps just another review section) and give brief summaries of what they do and provide links to old posts concerning those modules.

Granted, this is no small task and if someone has a better approach that would require less work, that would be great. I was just thinking that a nice categorized list of popular modules with some notes by other monks might be very useful. (At least I'd find it useful.)

- Sherlock

Skepticism is the source of knowledge as much as knowledge is the source of skepticism.

Hmm, I wouldn't use 'sprintf' as a search term for this particular
query, I'd choose terms like 'date format' or 'date string' or
something. And, while neither of those queries turned up POSIX.pm
on either CPAN search engine, both engines did turn up Date::Format
with the 'date format' query.

I have been programming perl for a while: seriously in the last year and sporatically before that. I often find here on Perlmonks some reference to a CPAN module that would have helped me at one stage of some project or another. Some are recent additions to the repository (e.g Text::xSV and Tie::Cycle) while some did not turn up with searches I made.

One problem is that in the heat of programming, one does not often see how to generalize one's problem and then describe it in a way a CPAN search can find it.

Finally, it was a great pleasure when I found CPAN.pm. It was not installed by default on my systems. Maybe one way to help promote the use of CPAN is to get more installations to include CPAN.pm by default.

One problem is that in the heat of programming, one does not often see how to generalize one's problem and then describe it in a way a CPAN search can find it.

Yup, this is precisely where perlmonks shines. Not only will people re-describe your problem for you, they will give you answers too.

So here's the problem as I see it:
CPAN seems mostly useful if I know exactly what I'm looking for. Perlmonks is a great resource but people can take advantage of the monks. The perlmonk search sometimes rocks, but sometimes it's really frustrating, again if you don't know what you're looking for.

Possible solutions:

Starting from CPAN.
The WAIT search is good to narrow down your search terms; it indexes module POD files and does OK on many-word searches. But WAIT is somewhat slow and the results are one-line links so you need to do some more digging in each result to find your search terms.

Starting from google.
Doing a google search restricted to site:perldocs.com works as well, and perhaps better. perldocs.com indexes POD files and other perl documentation, and has two lines of context for each result, which is very useful. The higher-ranked results are usually close to what I was looking for.

Ultimately what I'd love to see is an integrated CPAN/perlmonks search, where search terms are weighted like google's, and results from perlmonks are also weighted by their reputation.

When putting a smiley right before a closing parenthesis, do you:

Use two parentheses: (Like this: :) )
Use one parenthesis: (Like this: :)
Reverse direction of the smiley: (Like this: (: )
Use angle/square brackets instead of parentheses
Use C-style commenting to set the smiley off from the closing parenthesis
Make the smiley a dunce: (:>
I disapprove of emoticons
Other