Perl 5.16 and Relevance [LWN.net]

Perl 5.16 and Relevance

Posted Sep 14, 2011 14:14 UTC (Wed) by dskoll (subscriber, #1630)
In reply to: Perl 5.16 and Relevance by kragilkragil2
Parent article: Vincent: Perl 5.16 and Beyond

As others have mentioned, Perl is used with in lots of plumbing. Many Debian system admin scripts are written in Perl (though the quality of said scripts is uneven at best.)

High-profile Perl projects include SpamAssassin, Catalyst (on which a bunch of web sites run), RT (a ticket-tracking system) and Slashcode (that powers slashdot). Admittedly, these are not new projects, but they are actively maintained.

Perl is also used a lot in bioinformatics, I believe. Of most interest to me, my company's (non-FOSS) products are written mostly in Perl.

(Log in to post comments)

Perl 5.16 and Relevance

Posted Sep 14, 2011 17:57 UTC (Wed) by andrel (subscriber, #5166) [Link]

I know bioinformaticians who still use Perl. But there's a strong trend towards using Python or R.

Perl 5.16 and Relevance

Posted Sep 14, 2011 21:57 UTC (Wed) by dskoll (subscriber, #1630) [Link]

Totally useless and meaningless statistics from my Debian Squeeze system:

$ echo /usr/bin/* /bin/* /usr/sbin/* /sbin/* | wc -w          
4619

$ file /usr/bin/* /bin/* /usr/sbin/* /sbin/* | grep -c shell.*script      
621

$ file /usr/bin/* /bin/* /usr/sbin/* /sbin/* | grep -c perl.*script
420

$ file /usr/bin/* /bin/* /usr/sbin/* /sbin/* | grep -c python.*script
198

So shell (typically Bourne shell) is ubiquitous, Perl looks solidly entrenched and Python is indeed up and coming.

Perl 5.16 and Relevance

Posted Sep 15, 2011 3:46 UTC (Thu) by k8to (subscriber, #15413) [Link]

I was going on some wiki and email policy statements as well as seeing a few key tools move to c or python. python for example is the recommended interface these days to apt.

But there are plenty of debian developers who do not view a sort of vision statement like that as very important so yes some perl tools will remain forever as sprout anew.

Perl 5.16 and Relevance

Posted Sep 15, 2011 22:58 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]

Debian has been moving deliberately towards python from perl for their administrative tools.

There has been no such policy decision. Further, a subset of Perl (the perl-base package) is 'essential' (guaranteed to be installed) while no such subset of Python has that status. (Which I regret, as I would much prefer to use Python for complex maintainer scripts.)

Some utilities accompanying dpkg were written in Perl but have been rewritten in C so that 'Emdebian' installations can leave out perl-base as well.

Perl and bioinformatics

Posted Sep 16, 2011 13:55 UTC (Fri) by Kluge (guest, #2881) [Link]

I think part of the reason Perl is used so widely in bioinformatics is historical. But I think it's also because much of bioinformatics is text processing, and what is better suited for that than Perl?

Perl and bioinformatics

Posted Sep 16, 2011 15:34 UTC (Fri) by rgmoore (✭ supporter ✭, #75) [Link]

I think this is essentially correct. The problem in Bioinformatics, as in many areas, is that much of the early work was done in widely separated groups who weren't coordinating much. The result was a bunch of really good tools that don't play nicely together because they speak different languages. Rather than try to rewrite everything to work together perfectly, they stuck it together with a glue layer written in Perl. And of course once you have a setup in Perl that's the only thing that understands all the different languages, it's the natural choice to build new tools.

The result is that Bioperl now has literally hundreds of modules. Many of them are rather special purpose, but taken together they give you a very nice toolbox for solving your Bioinformatics problems. They may be a bit heavyweight- for some simple problems I find it's easier to write my own, lightweight solution than to read through the reams of Bioperl documentation to find the tool that does what I want- but that's the price you pay for the power and flexibility.