Jim Schueler wrote:
No apology please. In terms of trying to qualify any of this, a larger
statistical pool is better. And I am no authority. My perceptions are
largely based on forum postings which causes an inherent bias.
I'd love to see this conversation continue, especially if participants
included those who commit significant resources to their technology
decisions. In other words, people who hire and pay Perl programmers.
They're likely to be as skeptical as I am. I've never been a cheerleader.
In their absence, I'd note that your post has an interesting ambiguity:
Is the number of unsupported modules 2.5% or 25%?
Note that this was prefixed by "for the 10% remaining,", so it was indeed 2.5%.
My mothertongue is not English, so I am subject to the occasional linguistic
slippage.
It would probably have been clearer had I written "Of the remaining 10%,".
(For more rhetorical
nit-picking, you probably don't use the ones that don't work :)
Maybe. But I do use quite a few that do work and never needed any support.
And there are thousands of add-on modules in other languages that don't work and that I
don't use either. (So where does that leave us, statistically speaking ?)
I believe that Vincent's comment is right on the spot : perl, and perl CPAN modules, and
mod_perl, generally work so well that there are not a lot of support requests, and that
situation by itself makes them rather "transparent". "Happy people have no History"
(French proverb, translated literally).
There is a similar situation elsewhere in the IT world : some environments or applications
need a lot of support just to keep running. Therefore, they need a large support staff.
Therefore, their department grows larger and their boss gets a lot of clout and a big
budget. In contrast, the application which just works and doesn't require much support,
does not make headlines, tends to get forgotten and gets less staff, a smaller boss and a
smaller budget. Unfair but often seen.
Maybe the perl situation is not so bad in reality though. I have it from some usually
reliable sources that there is a gradual regain of popularity of perl among younger
programmers. That is certainly the case among the young programmers that I employ. They
usually arrive all infatuated by things java and PHP and .net and sharp, and look
sceptically at best upon anything around perl. Then they are asked to solve some simple
issues, and pick their preferred language to do it. Then they are shown the perl way of
doing it, and that generally succeeds in getting their attention.
It's a slow process, but one has to patiently overcome years of Java and MS propaganda,
and that doesn't happen in a day.
Also,
the significant question seems to be whether Apache::DBI is supported or
not.
From Mr. Zheng's point-of-view (in this case, the one that matters) the
number might be much higher.
-Jim
On Fri, 31 May 2013, André Warnier wrote:
Just butting in, apologies.
It may not have been Jim's intention below, but I get the impression
that his comments on CPAN are a bit harsh.
It is true that a number of modules are apparently no longer
supported. I have used many modules over the years, and sometimes
have had problems with some of them (mostly not though). And when for
these problematic cases, I have tried to get help, the results have
beem mixed; but the mix for me has been rather good. I would say that
in my case, 90% of the CPAN modules I ever used worked out of the
box. For the 10% remaining, in 75% of the cases I did get help from
the person advertised as the author or the maintainer, and in 25% of
cases I never got a response.
But then, as Jim himself indicated, people move on, without
necessarily changing their email addresses. Considering how old some
of these modules are, I guess people also retire, or even pass away.
But the fact of the matter is that CPAN is still an incredible
resource, unequalled in my view by any other similar module library of
any other language anywhere. And I find it amazing that at least 90%
of the modules which I have downloaded from CPAN and used over the
last 15 years, just work, and moreover keep on working through many,
many iterations of programs and perl versions, and that in fact one
very rarely needs additional support for them. When I compare this
with other programming languages and support libraries, I believe we
perl programmers are incredibly spoiled.
Another area where CPAN shines, is the documentation of most modules.
I cannot count the times where I was faced with a request in an area
of which I knew nothing at all, and have just browsed CPAN for modules
related to that area, just to read their documentation and get at
least an idea of what this was all about.
In recent years, Wikipedia may slowly becoming a runner-up, in terms
of general information. But when it comes down to the nitty-gritty of
interfacing with whatever API (or lack of ditto) programmers in their
most delirious moments might have come up with, these CPAN modules are
unbeatable. Even if after that you decide to program your stuff in
another language than perl, it's still useful.
(Just for fun, go into CPAN and search for "NATO" (or more
pragmatically, for "sharepoint" e.g.)(or even, God forbid, for
"Google" or "Facebook" ;-)); who thinks of such things ?)
So, to summarise : that some modules on CPAN would be marked as
"maintained" or "supported" and would turn out on closer inspection
not to really be anymore, I find this a very small price to pay for
the wealth of good information and working code that lives there.
My sincerest thanks to CPAN and all its contributors and maintainers
over the years (that includes you of course, Jim). What you have done
and are doing is of incredible benefit to many, many programmers
worldwide.
André
Jim Schueler wrote:
I still use Alpine. And they never fixed the bug where ctrl-c (to
cancel a message) and ctrl-x (to send) are so easily confused.
Oops. Maybe it's time to start using a mouse.
Having wasted so much time, I'll try to be succinct:
Most modules on CPAN are bascially throwaways and not supported at
all.
Use them at your own risk.
There are some modules that are just obsolete. Good intentions aside,
the developers lost interest and moved on. These are less risky if
there's an established user base.
There are some very good modules, widely used, that are fully
supported
and perfectly safe for a production environment.
Most mod_perl modules, especially the core modules, fall into that
last, gold standard, category. In many cases, support is transferred
from one individual to another. And so that commitment is
documented. But if a module is no longer supported, don't lie about
it. Support forums are an incredible resource. But if commercial
software developers similarly blurred this distinction, every p.o.s.
would be advertising free 24x7 tech support.
Apache::DBI seems like a #2 pretending to be a #3. On the basis of
your response, I've concluded that Apache::DBI is no longer supported
and has been superceded by newer modules. Especially if no one
responds and explicitly accepts the responsibility, this seems like
the most appropriate answer for the poster of the original thread.
I owe you a :) from a couple posts ago. :)
-Jim
On Fri, 31 May 2013, Perrin Harkins wrote:
Hi Jim,
I appreciate the thought, but I'm not the mod_perl list. If you
look at who
has done the most support around here recently, it's probably Torsten.
(Thanks Torsten!) More to the point, there are many people on the
list who
know enough perl to help with a question about Apache::DBI. It's a
common
practice to point people here for support on mod_perl modules.
What are you getting at? Is there a module that you're having
trouble with
and can't get support for?
- Perrin
On Fri, May 31, 2013 at 10:56 AM, Jim Schueler
<jschue...@eloquency.com>
wrote:
There's an existing thread with an Apache::DBI question. But
since I want to post a separate question to this list, I decided
to start a new thread.
Just got done reading the Man page for Apache::DBI. One of the
last notes suggests that this package is obsolete (having been
replaced by Class::DBI or DBIx::CLASS). Beyond that is the
following:
Edmund Mergl was the original author of Apache::DBI. It is now
supported
and maintained by the modperl mailinglist, see the mod_perl
documentation
for instructions on how to subscribe.
Unless Perrin Harkins agreed to take over support for this
module, then that statement is not true. Otherwise, out of
respect for Perrin, I'll try to be general.
(Aside: Am I the only developer that comes across 'unless () {}
else {}' constructions?)
It seems very few distros on CPAN are actually supported. For
my part, I still monitor this list to support my own
contributions from *many* years ago. And I k