Features Download
From: Fields, Christopher J <cjfields <at> illinois.edu>
Subject: Re: BioPerl long-term, was Re: dependencies on perl version
Newsgroups: gmane.comp.lang.perl.bio.general
Date: Friday 8th February 2013 14:08:56 UTC (over 5 years ago)
On Feb 8, 2013, at 5:18 AM, Leon Timmermans 

> On Thu, Feb 7, 2013 at 10:36 PM, George Hartzell 
>> But I'm so sick of getting into arguments (or walking away from
>> them...) with Ruby and Python [and lisp and *PHP*] fans; Perl is dead,
>> you can't write good code in Perl, look - Ruby has GEMS!, etc...
>> Perl of the olden days was an easy language in which to write really
>> shitty code.  Even the Perl of the BioPerl heyday wasn't really much
>> help; role your own OO, role your own distro-building, mountains of
>> monkey-work to provide consistent POD, versioning, etc...
>> But that's not the Perl that I use.  I have Moose and Moo.  TAP and
>> the things built on it.  Dist::Zilla.  PerlTidy.  PerlCritic.  cpanm.
>> MetaCPAN.  Pinto.  GitHub.  Perlbrew.  Wow.
> I share that experience.
>> But BioPerl *is* dying.  You might be standing on the shoulders of
>> giants when you use it to solve a problem, but you *definitely* have
>> those same giants (and their extended families) on your shoulders
>> every time I see you try move the project forward.  All of that
>> history has become the tail that's wagging the dog.
> I share your sentiment. Most of BioPerl is architected so badly I
> can't stomach it most days, and I've worked on hairy codebases
> included perl itself. There's just too much sick and wrong. It's like
> hundreds of dot-com-era cgi scripts.
> The problem (which is common in scientific computing) is that once
> code works it's effectively abandoned. BioPerl is essentially a
> gathering of more than a thousand such modules.

Yep, the progression from 'it works' to 'it works very well' tends to have
very high activation energy.  Many of the fixes tend to be more bandaids
(get it working) than fundamental surgery.  I tried my hand at this, got a
few things done.

>> If all y'all are going to keep the thing alive, moving forward and
>> contributing to new great works then make Apple your hero.  Deprecate
>> the stuff that's holding you back, give folks a path forward and move
>> on.
> That would be lovely, but who is going to do that? We're suffering
> from the tragedy of the commons.

Spot on, but we could break that path for the time being.  I think BioPerl
as is will have to be in maintenance mode; we need a new effort to break
with older perl, older practices.  

>> Have fun.  Use sharp tools.  Do cool science.  Build cool things.
>> Advance your careers (forgot that one last time).  Be reasonable and
>> professional.
> Sounds like good advice to me :-)
>> Supporting last year's projects is someone else's business
>> opportunity.
> True!

We just need to make a bioperl 1.x branch for the maintenance bit,
rechristen 'master' as 'v2', and just move on to fixing the f****** code. 
Let's move on that.

>> ps.  Are all y'all following this thread?
>>     http://news.ycombinator.com/item?id=5123022
>> Maybe someone should search down for this bit: "Where to start? Any
>> list of this [sic] projects?" and insert a plug for the various
>> open-bio projects.  (But "someone" doesn't work here, he said...).
> Interesting discussion, though the original post is too cynical even
> for my taste.
> Leon

Yes, that's not unusual unfortunately.  We have a number of physicists and
mathematicians here who have started their initial forays into
computational biology, they're all startled at how noisy it is and how
messy code can.  Of course their disciplines have had the benefit of
teaching students how to (somewhat decently) code for the last 40 years.

CD: 3ms