powerman wrote (Sep 15, 2006):
Few days ago I've asked about Reliable email parsing and
that discussion uncover some points:
- People doesn't need reliable perl modules, worksforme is enough.
- People even doesn't understand what reliable solution is good thing which
must be first priority goal (even if you can't reach this goal right now)!
- CPAN == goodness. Use CPAN module - is only recommended solution for anything.
If you say all existing CPAN modules for {any task here} is wrong because
{any reason here} - you got a lot of '--', no matter is you right or not!
I downvoted this post -- not the poster -- because it signifies an erroneous
mental process; the poster reached incorrect conclusions. I downvote those
incorrect conclusions.
In brief here's what's incorrect (and btw I've gone through and upvoted the other
reply nodes that say the same thing ;-).
People at Perlmonks "don't do anything in reply to questions but say use
such-and-such CPAN module for that" (paraphrased). (BTW, paraphrasing
isn't "putting words in someone's mouth", especially when the original words
were barely parseable English to begin with. Nonetheless I will of course
welcome and acknowledge corrections from the OP if he feels that I got anything
wrong).
It's a grossly inaccurate generalization, is what's wrong. The very diverse
Perlmonks membership comes up with many different sorts of recommendations
in response to questions.
People at Perlmonks "claim all CPAN modules are reliable solutions". Nowhere.
Never. Well, hardly ever. In fact it's a basic and established understanding among knowledgeable
Perl people that CPAN contributions vary widely in quality, from the sublime
to the absurd. If that informal but widely referred-to (directly or indirectly)
understanding never percolated through to the OP, that's too bad. Maybe it
does need to be stated more often. But in direct answer to the direct question
"Can I rely on it just because it comes from the CPAN?", I've heard no one
ever reply "Of course" or anything like it.
"People even doesn't understand what reliable solution is" =>
"People don't even understand what [a] reliable solution is" ...
Wrong because it is also grossly generalized, but partly true because it is
grossly generalized ;-). Perlmonks possess all sorts of degrees of understanding
about what quality is, in perl code. Some here have demonstrated the highest
awareness of the value of workmanship and pride in one's craft, and some
here fall far short of that. Some haven't yet really tried to show what they've
got it in them to accomplish, because, perhaps, they fear to fall short of
an ideal. In general, though, one thing that characterizes the concerns of
people in the Perlmonks community is quality and correctness, far
more than you'll find in nearly any other Perl-oriented project or site
anywhere.
I'll just point out that one thing which demonstrates one's own pride of
workmanship is the degree to which one makes efforts to create clear and
readable documentation for one's own projects, and by extension, to ask
questions or comment to others in clear and readable lingua franca
of hackerdom (that is, English). A NNES* could ask for someone with better
skills to proofread his-or-her writeup before posting. That would
set a good example, would show walking-the-walk instead of just talking-the-talk.
* NNES: Non Native English Speaker
As for what the OP (powerman) got mostly right:
Yes, "they all are low-level modules, each doing small simple task" has
considerable truth to it. And that actually makes sense, and is in keeping with
the original Unix philosophy of having a rich toolkit of many small tools which
is each specialized and optimized for its task (and then connect them together
into larger assemblies as needed). Perl came from the Unix world. It's sadly
true but also perhaps not unexpected that quite a few modules that work on a
higher level, which are on CPAN, are not of such high quality. Some are not
maintained -- they workedforher for the original author but that author
wasn't fully committed to portability and bug-stomping (which can end up being
nearly a full-time job in itself, or seems that way at certain moments).
I say "ANY software", but especially this important for all reusable things like perl modules and core things [...
All Perl modules are not "equally reusable". That's a mistaken idea. The basic notion of
modularity in Perl is simply the facilitation of extending the language to
accomplish different tasks in better ways. "Tasks" in turn are rationally
categorizable into "less" or "more" specialized. The more specialized the task,
by definition the fewer users need to do it. No?
There are problems with CPAN and over-reliance on it, I agree. I've seen it grow
worse recently. Newer modules are being released which, while not especially
low-level (i.e. they are more specialized) are nonetheless of interest to a lot
of people, and these modules in turn are relying on prerequisites (dependencies)
on CPAN that are failing tests on at least some platforms and aren't being fixed.
There's a "quantity over quality" attitudinal problem on the part of some of the
most prolific recent CPAN contributors that is degrading the overall reliability
of the Perl-CORE+CPAN system and it shows up most negatively where the modules
in question pertain to Perl admin and development itself, i.e. building, packaging
or installing Perl modules in various ways. These tools need to be the most tested
and robust (IMHO) because getting all other CPAN offerings relies on them to be
working. I don't know what to do about this trend. Partly I hope it will just
correct itself.
Soren A / somian / perlspinr / Intrepid
--
Words can be slippery, so consider who speaks as well as
what is said;
know as much as you can about the total context of the speaker's
participation in a forum over time, before deciding that you fully
comprehend the intention behind those words. If in doubt, ask
for clarification before you 'flame'.
-
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.
|
|