On Mar 27, 2009, at 5:08 PM, Joe Schaefer wrote:
----- Original Message ----
From: Octavian Râsnita <orasn...@gmail.com>
To: modperl <modperl@perl.apache.org>
Sent: Friday, March 27, 2009 5:26:43 PM
Subject: Re: decline and fall of modperl?
From: "Joe Schaefer"
The original message that started this thread was:
"""
One of our customers is doing a detailed review of a mason/
modperl ERP > app
we've built for them since 2001. Prodded by some
buzzword-compliant consultants they are expressing concerns that
the > app's
underlying technologies - perl, modperl and mason - are
becoming obsolete. They feel that a web application framework
must have
'rails' or some other buzzword in its name.
"""
"Consultants" who don't contribute anything to this community
aren't our
concern- nor should they be.
If they are consultants, it means that they contribute. The
contribution is not
only made of code and POD documentation or translations, but also
of answers to
the questions put by others.
You're not even in the ballpark. Consultants are hired and fired
based
on the quality and relevance of the information they provide. They're
supposed to make recommendations based on what is in their client's
best
interests. That's not a contribution to this community nor any other,
it is a *paid for* service.
A contribution to a *community* would be to offer gratis advice on a
mailing list, ostensibly to help the community reach its objectives.
Nothing I see in this thread looks like a contribution to the mod_perl
community, sorry.
I'm not really sure why it wouldn't be a good idea to try and educate
consultants about the value of Perl / mod_perl. It seems to be
consultants have a lot of influence over what tools get used for
projects they work on. The fact that many don't have much if any
exposure/knowledge of Perl and mod_perl certainly hurts the Perl
community. Discussing the advantages / disadvantages of Perl and
mod_perl so that we can all help educate the consultants and
institutions we work with about how mod_perl can benefit certain
projects seems like a rather important task.
Of course this question should be answered with language
comparisons,
Hardly. What matters is the quality of the software and whether
or not
it meets the customer's needs. There's nothing wrong with
recommending
the "right" tool for the job, even if the "right" tool isn't
implemented
in perl.
The question wasn't about the quality of perl, but the poster
wanted to know if
Perl/Mason/mod_perl are obsolete.
A language could be very good but obsolete because there are other
better tools,
or because other tools are prefered even if they are not so good,
and it could
be easier to find programmers that use those new tools.
and of course that those answers should be based on our opinions and
experience,
because if there would be very scientific studies that show which
of the
languages are modern and which are obsolete, which are good and
which are bad,
it could be very simple to find the sites with those scientific
studies using
Google and it wouldn't need to be asked on a mailing list.
Here is a good article written by Ovid - "Perl 5 is dying":
http://use.perl.org/~Ovid/journal/38010?from=rss
We should also remember that somebody discovered that perl 5 is
dying 9 years
ago, and this was the thing that created the idea of perl 6, that
should be
totally different.
Languages don't die, they aren't people. People will continue to
use
perl5 for the forseeable future, even after perl 6 is finally
released.
"Die" is just an expression that wants to tell that the language is
not used by
more and more programmers, but by fewer.
Usage statistics are irrelevent to the vitality of a language.
What's relevant
to the perl community is something like how many module maintainers
have abandoned
their codebases. Do you have any information about how many modules
are on
CPAN that are no longer supported? And to bring it back to
mod_perl, how many
of those are Apache modules?
It's hard to argue that Latin is on the same footing as English when
Latin is only spoken by a tiny handful of people even though it has a
lot of great history. Technology, like language, generally lives and
dies by its user-base. Usage is also directly related to developer
enthusiasm in most cases. A developer isn't going to want to spend
time maintaining a module if no one is using it. It's a lot easier to
justify spending weeks or months getting a module ready for CPAN if
you have some reasonable expectation that a lot of people are going to
benefit from it.
