The obvious, and probably correct, answer is ‘probably not essential‘ but if you work in software configuration management it is well worth considering.

Perl is fairly ubiquitous, there are few platforms that do not have a Perl implementation available and it is a standard part of many Unix distributions. Perl code is (with a little caution needed to avoid explicit platform dependencies) portable too, the Tk packages even provide a reasonably portable GUI system should you need it. Perl is a fairly simple language to learn and has a legacy of library code freely available from CPAN that offers a multitude of useful utilities to the SCM practitioner.

While a similar case can be made for Java or Python, I contend that, excellent skills to have though they may be, both languages place more demands on the casual programmer, requiring more time to learn and more discipline to write code. Perl benefits from a much more relaxed approach to scripting. Being a semi-compiled scripting language it is easy to write quick scripts and easy to develop these in a more-or-less ad hoc way.

It is undoubtedly true that Perl’s relaxed approach can bite the unwary, and it is very easy to end up with unmaintainable systems if you let them get out of control. But with a little discipline you can, so to speak, have your cake and eat it — benefiting from simple, rapid scripting facilities, leveraging libraries and ease of developing small scripts into greater things.

If you get serious about your Perl then you will need an IDE. I use ActiveState’s Kermodo and it serves well with its integrated code assistance, online help, coverage analysis, and debugger being major benefits. Activstate’s Perl developer package also comes with a nice packaging tool that wraps a Perl interpreter with your code to provide a single executable package that does not require Perl to be installed on the user’s environment.

If your tastes run more to the Eclipse IDE then there’s an extension for Perl, which also supports the Perl debugger, called EPIC. Having used both, I favour the ActiveState environment for all the additional features their package supports, but that’s a personal choice.

Over the past fifteen years I have found my Perl skills have enabled me to quickly develop and reuse Perl scripts in many different environments, on many different projects, for many different clients. So, for me, Perl has been one of the skills I have been very glad to have in my toolbox.

As with most people who have worked long enough on the coalface of SCM I have a ragtag collection of routines, scripts and utilities already but now is the time to pull them all together, clean them up, give some thought to a coherent design and build a better mousetrap that I can use whenever I go to a new client.

This is not an effort to develop a be-all-and-end-all CM system, but more a matter of me realising that I develop the same sort of scripts time and again. So I would be better off developing a more robust architecture that will allow me to exploit report generators or integrity checkers written when using one tool when I go to a client who uses another tool but has the same problem to be solved.

A typical example of a script I have written several times is one to check the integrity of a build configuration. Answering questions such as, ‘does this build configuration contain all, and only, the completed change requests assigned to this release?’

It would also be nice to have a tool for federated reporting across tools. Often clients have several version control tools and it would be nice to have one reporting front-end that I could plug into their many VCSs and get information about them all.

There are, of course, many problems to overcome (not least all the different philosophies supported by these tools) but this is not a case of trying to solve all problems in one go, rather the idea is to write a facade that will allow me to access the implementation tools through a common interface. In this way, all I need do for each client is write a new facade that complies with my own interface definitions but interrogates their particular implementation. The hard parts of these scripts, the logic, will remain unchanged and useful in multiple applications, treating the tools as databases.

As with many efforts born of frustration, this one is not completely thought out yet (in fact some of the ideas are positively vague), so expect more to come on this side project…

There are a multitude of technologies that can be used to create glue software, including but by means limited to; SQL, various shell scripts, C, C++, C#, Java, PHP, Python, various web technologies (XSLT, ASP etc.) and so on. Over the years I have used all of these and more but by far and away my favourite glue software development language is PERL. And here’s why…

PERL is ubiquitous. There is almost no regular platform on which PERL cannot be run; Windows, *NIX, Mac and Mainframe are all generally covered and therefore most of the platforms one is likely to be using in a modern CMS are covered.

PERL is simple. Well, more accurately, PERL is easy to teach/learn because it is accommodating, typically providing more than one way to express a programming notion. PERL is a fairly forgiving language, but it has to be said that sometimes this flexibility leads to confusing pieces of code. One soon learns to interpret the more idiomatic usage though and the confusion is lifted leaving only the choice of programming approach afforded by PERL’s flexibility.

PERL has a vast library of freely available libraries. Like many languages that are available across multiple platforms, PERL has developed a wide following from many disciplines and this has meant the development of a large library of routines to do almost anything you want. Check out CPAN and look through all the modules available there. To paraphrase Apple’s App. Store tag line, ‘there’s a PERL module for that’. This facility alone can save hours of tedious programming.

Write it once, use it anywhere. Using a native script language (such as ksh, Bourne shell, or even – shudder – BAT) means you are largely tied to one platform. PERL’s ubiquity, when combined with careful programming, means your carefully crafted and debugged script will work pretty much anywhere.

PERL has a long and illustrious career as a web programming language. Pre-dating Java, PHP, ASP and others as serious dynamic web technologies¹ the Apache mod_perl module has allowed PERL code to be embedded in web pages for many years.

With PERL modules like Tk (or Tkx) you can create graphical user interfaces for your scripts that adapt to the window system on which they are displayed. (The newer Tkx provides a much more raw interface to the underlying TCL/Tk libraries. It also, to my eyes, produces a better UI that matches more closely the host platform. Basically because the TCL/Tk libraries are more up-to-date than the Perl/Tk implementations.)

So, that is in broad strokes my case for PERL. But there’s more.

Perhaps the best supported PERL package is that provided by ActiveState. Although hardcore PERL mongers may consider this limiting I suggest (especially to new PERL users) using ActiveState’s installation and limiting yourself to using the packages provided through there PERL Package Manager from their repository.

Although ActiveState provide only a subset of available packages it is a substantial subset and, more importantly, they work across all the platforms supported by the main ActiveState distribution. This in turn means that the write once, use anywhere philosophy is easier to maintain.

Added to this common support facility the ActiveState PERL Developer Kit (PDK) provides a cross platform packaging facility that means applications developed on one platform can be wrapped into executable packages suitable for multiple target environments. So, if you develop your PERL on Mac OS X you can provide packages targeted for Windows, Solaris, Linux and AIX platforms without ever leaving your OS X environment. And that has to be a good thing.

As if this were not enough, the PDK also provides the means to package your PERL as a Windows service, a dll, a System Tray utility, or a .NET library (making your PERL libraries available to your .NET developers).

As with any broad statement, claims of PERLs utility must be accompanied by a cautionary note. The path to PERL Nirvana is not an easy one. Not all PERL modules are of a high quality. Not all PERL applications will easily package using the PDK. And not all PERL code will work on all platforms. Just as with any programming language you, the programmer, must be aware of platform differences and ensure your script will handle them gracefully.

All this said, with a little forethought and care PERL provides a powerful platform for glue software and more.