On Thu, 9 Apr 2009, Eric Wilhelm wrote:
A common plaint I hear about perl code *from people outside the
community* is that we have too many dependencies and our code is too
hard to install. ?... ?If on top of that you want
them to *upgrade perl* they're going to think you're mad.
Ruby didn't seem to have a problem getting installed.
There's a huge difference in installing a new software stack altogether and
updating something that's there by default on just about every UNIX out
there. Given how many OS's use Perl scripts for administrative tasks I
wouldn't necessarily be surprised to learn that some of them also bundle
some CPAN modules with their package just to keep that running. So, if your
vendor doesn't update the system perl, you shouldn't be overwriting it with
no regard to the consequences.
Even more so when you have people installing modules via CPAN and
outside of package management. They always run the risk of updating perl
and forgetting a litany of other modules that were installed for various
scripts, etc., which use XS modules, etc. The anticipation of that kind of
triage is more than enough reason for a lot of people to avoid updating
perl. How many sys-admins and non-developers are aware of perlocal.pod?
I've never heard "we don't use Perl because it's hard to install", I've
only heard "we can't find programmers".
Perl isn't hard to install. It is not, however, trivial to upgrade without
having a lot of unintended consequences for the reasons I detailed above.
If the recommendation is to install a new version of perl in /usr/local,
then this becomes much less of an issue.
The recommendations we make to new programmers are met with limited
patience. Do you recommend that they use EU::MM on account of
M::B "not working" on a system which hasn't been upgraded in 10 years?
IMO, that's getting off on the wrong foot for reasons which aren't
worth it. By the time you need to explain how to do something special
with EU::MM, you could easily explain the compatibility issues of M::B
and the boring history lesson (and if you've gotten that far, we've
passed "newbie".)
There are definitely cases where you would want to abandon EU::MM, but you
have to do so with the conscious realization that you're reducing the size
of the audience that could benefit from your code at that point. If getting
a complex installer working under EU::MM is that painful I can certainly
understand you not wanting to make that sacrifice. It's all good. But as
long as there are more installations out there with EU::MM than there are
M::B it only makes sense that you accomodate them where you can, so the
largest segment of the community gets the benefit.
Ultimately, isn't that what matters? If we didn't want to make a
contribution we wouldn't be releasing it on CPAN, right? For that reason
I'm going to wait until M::B becomes predominantly available before
considering a switch. Until then I use EU::MM and still test against Perl
5.6.
--Arthur Corliss
Live Free or Die
