bryandunn.com

I’ve been using Perl since 2001 in a variety of roles beginning with systems administration. For the last few years I have been a “Software Engineer.” I put that in quotes because popular opinion states that using a scripting language to develop software somehow makes you less of a Software Engineer. Users of languages like Java, C, C++, etc argue that a language like Perl does not have the proper restraints to force developers to write elegant and understandable applications. In some respects, they are correct. A scripting language like Perl allows developers to make their code barely legible. There are plenty of open source applications you can download that prove this point. Yes I’m sure I could find some open source Java project and find that it’s pretty ugly too, but for the most part you would find that most Java programs look a lot alike and won’t vary in style (and stability) as much as scripting languages.

A lot of this is due to the enforcement of standards. As an example, let’s look at a method/subroutine that gets the greatest common denominator in Java and Perl.

In Java:

private int gcd(int num, int denom)

{

    while (denom > 0)

    {

        int q = num/denom;

        int r = num - q*denom;

        num = denom;

        denom = r;

    }

    return(num);

}

In Perl:

sub gcd

{

    my ($n, $m) = @_;

    while ($m) {

        my $k = $n % $m;

        ($n, $m) = ($m, $k);

    }

    return $n;

}

Just by looking at the code you know these things about the Java that you do not about the Perl:

1. Return type
2. Argument types

Also, if you try to pass the wrong number of arguments or incorrect types of arguments to the Java method, you will get an exception. In Perl, you will end up with a logic error because the Perl interpreter WILL do the computation for you but you are likely to get a bad result. Sure, there is always the “Garbage in, garbage out” to fall back on, but it would be nice if you knew going forward that your code could potentially give you a bad result.

There are lots of instances like this where Perl will give developers enough slack to hang themselves. Without variable or return types and declarations, developers can make their code very unstable. Languages like Java force developers to think things through by requiring variable and return types. This makes the language more difficult to pick up, but has the benefit of requiring the developer to know what they are doing to write the code. Of course we can all find examples of horrible design and code in any language, but you will find more examples in languages such as Perl that are so easy to pick up.

What differentiates the “scripters” from the “developers” the most is not the language however, it is adhering to good software development practices. Someone using Java probably has a background in software development while someone who uses Perl could be from any number of backgrounds. Systems administration is where I picked up Perl and I’ll be the first to admit I’ve written some pretty bad scripts in my years. Since moving to development however, I’ve learned that by adhering to solid software development practices, even scripting languages are viable choices.

Why use Perl?

The main reason I use Perl is that I find most tasks easier to code. It takes far fewer lines of code for most tasks in Perl as it would in Java or some other traditional development language. Due to the nature of my job I also do a lot of file IO and communicating with the Operating System. There are few better choices than Perl for these tasks. Also, there are a vast amount of modules available on http://cpan.org that you may use with relative ease for most tasks. If you can think of it, chances are someone has already written it and made it available via cpan. The lack of “types” in Perl can either be a blessing or a curse depending on how well you write your code. Sure it saves time and gives you a bit more freedom not having to worry about declaring types for your variables and subroutines, but on more than one occasion I’ve used the string comparision (cmp) operator in place of it’s numeric counterpart (<=>).

Below are some of the things that I have learned in my experience as a software engineer to make Perl a more attractive option for development. I think there are enough benefits to using Perl for some projects (yes, there are plenty of projects out there that are better suited for Java or some other language) to work around it’s shortcomings.

use strict;

This is one of the most important things you can do to avoid the common pitfalls of using a “scripting” language. The ‘strict’ module makes you specify scope for all of your variables so you don’t step on any unintentional globals or use more memory than you have to.

Enable warnings (-w)

If you are doing something potentially stupid, using warnings will usually give you a heads-up. This offers you some protection from yourself and Perl.

Use a main() subroutine

No this is not required by Perl. You may in fact simply open an editor and create a 3,000 line script that does not include a single subroutine. In all of my scripts I have a stanza that looks like this:

main();
sub main
{

.......

}

The advantage I gain from this is that I always know where to look in every one of my scripts for the start of my program. In fact, this lies right in line with using……

Coding Standards

There are many tools that allow you to apply standards to your code in traditional development languages. I do not know of any for Perl, but that doesn’t make it any less important. Taking simple steps to ensure consistency make your code much more readable for other and yourself when you go back in a year and try to figure out how something worked. This doesn’t have to be too constricting, it needs to ensure consistency. Some of the things I always include:

• Constant variables are all upper-case, words separated with an underscore (MY_CONSTANT)
• Global variables begin with an upper-case letter, words separated with an underscore (My_Global)
• Locally scoped variables are always lower case, words separated with an underscore (my_local)
• Each word in a subroutine name begins with an upper case letter and does not include any underscores (MyFavoriteSub)
• ‘use’ statements, constants and globals are always declared in the top of each file
• Always put braces on a new line
• Every subroutine includes the following subroutine header:

#################################################
# Description:
# Arguments:  arg1 (type)
# Returns:  arg (type)
#################################################

Use an IDE

There are a few out there for Perl. I use the EPIC Perl Eclipse module. I know a lot of people who are happier using vi than an IDE. Typically an IDE does give you some advantages however, such as syntax highlighting, error checking, etc.

Compile

One of Perl’s drawbacks, especially if your project uses lots of modules, is that you need to install all of these modules on every machine you are going to run your code on. There is a product called the Perl Developers Kit (PDK) from ActiveState (which I own no stock in) that allows you to compile your applications into binary format. It supports Linux, Solaris and (if you must) Windows. What it does is bundle all your code together with a trimmed down version of the Perl interpreter and all the modules your code uses in a binary that you may run without even having Perl installed on your system. As an added benefit, if your code is company sensitive (or just sensitive to you) you don’t need to give it to your users.