As in certain cults it is possible to kill a process if you know its
true name.
— Ken Thompson and Dennis M. Ritchie
I’ve been thinking recently about what accounts for the
true. I’ve been trying to work out what accounts for the
Archive and Python’s Vaults
of Parnassus comparative failure.
There are many reasons. First, there’s a clear distinction in CPAN
between libraries and applications; the RAA the Vaults don’t have such a
thing. But I’ve come to the conclusion that a major factor, and one
which applies both to collections of software such as those we’re
looking at and the development world in general, is the way that
libraries and aplications are named. (To be fair, Ruby is getting better
at this and beginning to solve the problem the Perl way.)
I’d like to give a couple of principles for naming software.
- Definitive names discourage wheel reinvention
- Descriptive names are best for libraries
- End-user projects can have non-descriptive names
Perl’s modules are generally given simple, definitive names. If I
want an XML parser, I head for XML::Parser. It’s that
simple. (Of course, if it’s not that simple, I head for
XML::Simple which is.)
If I want to write a module for parsing XML and I know that
XML::Parser exists, I’m forced to choose a name which
correctly denotes what sets my parser apart; I have to do something
new, and hence I’m not reinventing the wheel.
There’s a temptation to make up cutesy names for software projects.
However, when it comes to libraries, this is more of a hindrance
than a help. When I see a module called XML::Parser I
know exactly what it does. It doesn’t require any more description.
If, on the other hand, it had a cutesy name - Expat - I
would have no idea. Similarly, good naming helps me quickly locate
the library I need. If I’m writing C code to deal with Unicode, I’d
look for a libunicode. And behold, there is indeed a
libunicode which does what I want and I need look no
further. That would not have been quite so easy if it had been
called libgeoff. Cutesy acronyms don’t help either -
you might know that libgail is the GNOME Accessibility
Implementation Library, but at first sight, that might have been
called libgeoff too. Why not, say,
libaccess, or libgaccess if you must have
the g for GNOME.
There is a place for cute naming, and that’s in applications and
other end-user projects; this is because there’s more space for
competition. You’d never get away with calling a web browser
“webbrowser”, so “Mozilla” is as good a name as any. However, if
you’re building that as a Perl module, then
Web::Browser (or Tk::WebBrowser) would be
just fine. This should remind you that some things that you think
are applications can turn out to be libraries, and vice versa -
consider spamassassin as an example. Thankfully, that has both a
catchy and a descriptive name, so turns out to work very well as
both a library and an end-user tool.
Shamans have long known the value of the correct and definitive
naming of things; programmers of libraries and modules would do well to
rediscover it.
