I've been writing and rewriting Nama[1,2,3] for several years now. It's been my introduction to intermediate concepts in computer science.

Nama is an audio recording, mixing and editing application, using Ecasound[4] as the audio engine.

I'm proud of how it has evolved. At first it was all procedural, driven by a command processor loop. Then I added a Tk-based GUI, my first GUI. I added a text interface with a command grammar based on Parse::RecDescent. I introduced OO to separate the code for two different UIs. Then I added classes for tracks, buses and other entities. I added an event system (actually two), serialization, a help system, tests. I created a build system to automatically generate parts of the grammar, the help system, and to merge various files. The code for audio routing has gone through three different design interations: hardcoding, routing by rules, and now, routing by creating and transforming a graph.

I've cleaned up, commented, refactored wherever it could help. I profiled and memoized to speed up my code. I refer to a shelf full of well-respected Perl books, follow PerlMonks and other forums of the Perl community. Most of the really hard stuff I've solved by accreting other programs and libraries, largely from CPAN.

It's been exciting, exhiliariating, and at times laborious, confusing and opaque. I've had users helping to test, suggest features, and occasionally hold my hand.

Despite all my work to keep the code legible, even users familiar with perl have a hard time reading the code. I'm feeling ready for a visit by the architectural review board!

After reading a number of articles advising against the use of global variables. I'm wondering: Should I be encapsulating the 250 or so global variables into objects? (Clearly, yes.)

What about the way classes reach into each other for data?

Maybe I should be re-architecting my tests? Expanding test coverage is hard, but necessary. I'll need a way to build a test environment that includes (or fakes) some WAV files and other project data.

Welcome, ARB, especially those of you who are musicians!

1. Nama - github
2. Nama - cpan
3. Nama - home
4. Ecasound

A lot of work is currently underway to improve CPAN. One longstanding issue is the handing of external dependencies (the "libfoo" problem.) As I understand it, although CPAN distributions may test for external dependencies, existing build tools are unable to install non-perl libraries, header files or compilers.

Resources to solve these problems are available, but in places not usually considered by CPAN toolmakers. I'm referring to native OS package repositories. While natively packaged CPAN distributions necessarily lag current CPAN offerings, they meet non-perl as well as perl dependencies, and are generally troublefree to install.

To give the example I know best, Debian's perl repository covers roughly 10% of CPAN, including much of CPAN's best. This enormous investment in labor, toolchain development and community building results in high-quality packages that even new users can install easily.

As a developer of a perl audio application available for Debian, I've encountered problems managing dependencies when administering systems that mix distro and CPAN sources, even when using local::lib.

One issue is that CPAN clients will always fulfill a distribution's dependencies from CPAN, even if native packages are available.

I'd like to suggest a small but significant step to bridge this divide between native and CPAN repositories: a native installer option for CPAN clients.

After a few false starts, here's a working demonstration: a patched version of cpanminus that supports multiple native installers.

You can invoke it like this:

cpanm --distro Debian Some::Module

causing cpanm to execute:

$distro_installer = eval {require "CPAN::NativeInstaller::Debian" }

$distro_installer then gets a chance to provide a native package for each distribution cpanm seeks to install. With this added ability, CPAN client users can install perl distributions from both native and CPAN repositories, and finesse the libfoo problem for a significant portion of CPAN.

What better way to encourage the resurgence in perl popularity than to help application developers administer their systems?