Reviews and Ratings
A recent discussion in the Emacs group on LinkedIn (http://bit.ly/7HAB3P) was headed: "Wouldn't it be cool if emacs expertise was somehow useful in finding a job?" The most penetrating response to this question was "Emacs expertise is actually useful in keeping the job." This is in a nutshell the reason I use Emacs. All the horror stories about the Emacs learning curve are true, but once you've achieved the summit, you are positioned for serious productivity gains--and without knowing a scrap of elisp. Rectangular cut and paste, line sort, and regexp replacement (sans mouse) alone have saved me dozens of hours of data hashing that my biologist colleagues would have spent clicking and dragging in Excel or worse. All my perl development (perl-mode) and debugging (gud) happens in Emacs, as well as all my remote site editing (ftp-ange), wiki pages (wikipedia-mode), and html (html-mode). I rarely open a Word document, except to paste in text composed in Emacs.
Etc., etc., etc. If there is a problem with Emacs, it is that it trains you into itself. When in another IDE, you feel like Steve Mann at airport security (http://bit.ly/6FLtNj). Consequently, this cannot be an unbiased review--for example, Eclipse sits idle on my hard drive, taking up however many hundreds of MB of space, because it's just not worth retraining my fingers. Maybe one day, after this quick tweak to bioperl-mode...
When you make the leap to coding your own packages, you might as well abandon hope of ESC ESC ESC. You'll have finally crossed the separatrix and are trapped (http://bc.tech.coop/blog/060302.html). But it's a happy place. Your hands are always on the keyboard working away. And as Zippy sez:
"...Get me a GIN and TONIC!!...make it HAIR TONIC!!"
Like any good organism, BioPerl appears to be evolving in response to selection. I love BioPerl, and it's become indispensable to me, but I'm a core dev, so that doesn't count. What does count, IMHO, is that though BioPerl is mature, it isn't ossified.
Last year, one of the cons on Ohloh's quick facts sheet was "declining year-on-year development activity". This year, that's become "increasing", in part because of a big push within the community to provide tools relevant to sequence bioinformatics today, which increasingly revolves around public data retrieval and next-generation sequence data handling. Rationalization of the enormous rats-nest of BP documentation is also underway--which really comes down to creating user-friendly entry points and natural link paths. Perhaps one of the best development efforts this year was simply improving the look and feel of the wiki homepage (http://bioperl.org), with the hope of making it more inviting, and more relevant to *users* seeking answers.
There has been a movement away from BioPerl and towards faster and more efficient tools in C in some circles of the sequence-crunching world. In some respects, this may be due to a drift away from the "glue code" focus that made BioPerl so very relevant during the years of the human genome race. Now, for many devs, OO Perl is just plain fun (= obnoxiously unintuitive and bloated, for others), and it may be that this has contributed to the drift into heavyweight and calculation-intensive modules. Current developement efforts (at least, MY current efforts) are taking the 'Art of War' approach of 'taking whole', providing run wrappers for popular and efficient external programs, and making it easy to plug their outputs into their inputs, and parse the results. Perhaps a return to its roots is just what BioPerl needs to stay fresh and relevant.