Of course I still use Perl

Over the past couple of years, my practice of developing and releasing software as Perl/CPAN distributions has spread to my other non-CPAN projects. Software are now being composed as collections of Perl distributions, although they are not released to CPAN (but some components are). I am embracing this practice because:

1) It encourages modularity, a desired property in software. Perl modules are logical groupings of code, and Perl distributions are units of deployment/release.

2) It encourages the "release often" (and release early too?) principle, which feels good. Instead of releasing a new version of software once a month or once every six month, you can release one or more distributions (i.e. components of your software) every other day. Progress is more visible and trackable. Deliverables are more concrete. There are more rewarding feelings of getting things done and pushing stuffs out there. Of course, how these distributions are packaged and finally released to your end users can be regulated according to company policy. Nevertheless, updates to your software can now be partial/incremental.

3) You get existing, established tools and best practices (for free). You can use cpanm to install modules not on CPAN (either by directly mentioning a tarball path/URL or even github URL). You get to use the standard Perl testing tools like prove/forkprove. There are Dist::Zilla and other distribution building tools available for you. For distributions getting released to CPAN, you get free distributed testing by CPANTesters. For distributions not released to CPAN, there's no reason why you cannot clone similar infrastructure.

4) Familiarity with users. This depends on who your target users are, of course, but if they are familiar with Perl/CPAN modules, they more or less know how to install your software and/or read documentation (perldoc).

There are drawbacks and limitations too:

-1) Complexity (though this issue is not specific to Perl-distribution-style). Breaking software into modules/distributions create more interface boundaries and interaction possibilities between the modules. This will be augmented if you need to support several versions of your product line (as most software companies do). You will need to decide which distributions need to be broken up to support old/new interfaces, or which are to be made to support several interfaces.

-2) Standard POD documentation format is not suitable enough to create more complex documentation such as user guides with tables/images. But there are tools that extend POD to make this possible.

Another blog post is coming on how I currently manage my collection of Perl distributions.