I like Perl

I am told that this is a fairly insane position for a real Computer Scientist to take. In an age where static checking, managed runtimes, virtual machines, etc. are king, Perl doesn't make sense. Even during my defense last week, Dr. Mizuno asked, "So, why did you do this in Perl? This language is very strange to me." So, I'm going to try and give a defense of my language of choice.

Flexibility. If there's anything a Perl programmer is looking for, it's flexibility. Perl's motto is, TMTOWTDI, or There's More Than One Way To Do It. In Perl, there are more like 10,000 ways to do anything. For example, all of these are common expressions for saying the same thing:

# TMTOWTDI #1
if ($x == 2) { $a = "Hello World!"; }

# TMTOWTDI #2

$a = "Hello World!" if $x == 2;

# TMTOWTDI #3

$x == 2 and $a = "Hello World!";

# TMTOWTDI #4

$x != 2 or $a = "Hello World!";

# TMTOWTDI #5

unless ($x != 2) { $a = "Hello World!"; }

# TMTOWTDI #6

$a = "Hello World!" unless $x != 2;

# TMTOWTDI #7

$a = $x == 2 ? "Hello World!" : $a;

# TMTOWTDI #8 (not exactly the same on false)

$a = $x == 2 && "Hello World!";

# TMTOWTDI #9 (ugly)

goto EVIL unless $x == 2;

$a = "Hello World!";

EVIL:

I could probably have come up with more, but we start exhibithing worse and worse style if we do. My point is, I can think in Perl. I don't have to reorder my neurons to operate in one style or programming or another as enforced by a language. Perl gives me the opportunity to program in multiple styles simultaneously depending on what suits my need at the moment: procedural, functional, object-oriented (there are actually several OO styles available), spaghetti (via goto), whatever.

Features: Perl has most of the same features as Sun Java, Microsoft .NET, and other "modern" languages/language platforms. Perl, despite popular belief, is a compiled language rather than interpreted. However, Perl is usually compiled from source on every build. This isn't a requirement, however, as it does have the ability to build objectcode and bytecode executables. In fact, there are tools to translate Perl into forms acceptable for both the Java Virtual Machine and Microsoft .NET—I've never used them, so I can't attest to their efficacy. Perl supports garbage collection. This garbage collection is performed via reference counting, so it's far from perfect (make sure you break any reference loops). It is a heckuva lot faster than the stop-and-copy style of garbage collection used by Java (ever notice Eclipse or JEdit just stop doing anything for 60 seconds or that a Java program takes up twice as much memory as necessary?).

Static Checking: This is a strong sucking point for Perl. However, my collegues often tout the beauty of Python and yet, Python suffers under the same problem. The problem is that both Perl and Python allow for runtime modification of the symbol table. Therefore, I can, as a Perl/Python programmer, create new functions, removing existing function, and replace functions while the program runs. It isn't a good idea to make a habit of doing this, but it provides a great deal of power when it comes to coding.

I'm sure Dr. Banerjee and Dr. Stoughton can probably prove that such constructs are unnecessary and that by using static code we can achieve much of the same power if we reduce these patterns down logically. Bah! I am not a mathematician, just a logician. I'd much rather have the Stoughton's and Banerjee's of the world make my code safe by creating new and better compiler technology than have to reshape my mind to fit some mold. (Yes, that's an emotional argument, get over it.)

On the other hand, static checking doesn't guarantee your code works. This is the common misconception the incoming freshman has when s/he says, "It compiled without errors, so it must be right!" Wrong! Static checking can verify that your code doesn't contain any typos and that did in fact make sure that you only used your numbers like numbers. It cannot say, "Aha! Your code does what it's supposed to!" No, only humans can do that. The guys working on verification software or ways to prove that code fits a specification are closer to finding the truth on this subject. The only way to verify that your code is correct is to either logically prove that your code does what it's supposed to and/or provide exhaustive test cases for all code. Since the latter is generally impossible (unless you have the next 40 trillion years to run your tests), proving the correctness of your code is your only fully correct recourse. On the really delicate parts of my code, that's generally what I will do. However, for the more general bits (input/output especially), I will create unit tests.

Unit tests are the only way to really make sure your code is generally safe. The more tests, the better. Using good testing strategies is also important. Anyway, it doesn't matter if your code is statically checked C++, OCAML, Standard ML, or loosely checked Perl, Python, or Ruby: You must either proof or test all of your code! Thus, I see static checking as helpful, but not the ultimate answer to coding problems.

Unit Testing: Perl has a built-in unit test framework called the Test::Harness. All you have to do is create your Perl Makefile (ExtUtils::MakeMaker) or Build script (Module::Build) and then dump a bunch of test scripts in the ./t directory. On more complicated systems, you may have to use a web server or web client or some other such thing to test your code. In this case, you can use Test::Harness directly to run the tests and write in any extra stuff you need. Unit tests in Perl are easier to write than any other testing framework I've used—I've not used Python's, so I cannot attest to it's abilities.

POD: Perl uses a documentation format called POD. This language is not powerful, but it is very simple. It's superior to Javadoc because it allows for the creation of complete documentation, not just API docs. I can write POD and have it translated into man pages, HTML documentation, printable documentation, or plain text. I can have it translated into custom formats relatively easily because the language is so simple. I've also used Python's docutils reStructured Text format and have to admit it is cool because it is so flexible, but the parser itself is not. If you want something else besides LaTeX or HTML, you're SOL.

Ugly: Perl is ugly. I will agree to that. However, are there any "pretty" languages out there? I haven't met one. I happen to think that Java is really, really, really ugly (do I have to cast back and forth to and from Object every time?). C++ is pretty ugly (ever use templates?) and Java 1.5 will earn the same ugliness with it's generics too. Python is just queer without any brackets or braces to start and end your statements, but is probably prettier than most (Mr. Idiot-Programmer can't format his code badly 'cause it won't run if he does). C is completely disgusting. OCAML and SML look like Calculus equations to me and I've already told you I'm not a mathematician.

I'm sorry, but this just isn't an argument that holds much water with me. The sigils ($/@/%) are the major intimidation, but once you know what those mean, it becomes worlds easier. Perl does have a context-sensitive grammar, which is a little scary as one statement can take on different meaning based upon which construct it's placed in. But that's the scariest part. Given this:

$x = 1 if $a == 2 and $b == 3;
$a == 2 and $b == 2 and $x = 1;

The context sensitive aspect of the grammar causes both of these to work as expected, even though the and might normally throw us off. For those who don't know, Perl has two "and" operators, and and &&. The former is the ultra-low precendence version. Therefore, in general, it is the very last part of a statement to be executed. The if here modifies the context of the and though, causing both of the above statements to be treated the same, parsed as if:

($x = 1) if (($a == 2) and ($b == 3));
((($a == 2) and ($b == 2)) and ($x = 1));

That is, the and in the first statement is executed before the if rather than after, as would be expected in a context-free grammar, but counter-intuitive to human reasoning. Anyway, Perl tends to do a lot of dwimming to help out the programmer. This can get a person into trouble sometimes, but I've found the rules to be intuitive more often than say the strict grammar rules of most other languages.

All of this to say: I think Perl is ugly, but no uglier than any other language once you understand it.

Perl 6: I'm holding out for Perl 6. Perl has a long history. As such, it has grown quite a bit and inherited much that is evil from it's earlier days. Many of the objections folks have had with Perl 5 are resolved with Perl 6. It looks like 2005 may see the debut of Perl 6 and it will be a good year if it does. Perl 6 rewrites Perl 5 from the ground up and includes (as I understand the writings of Larry Wall, Tom Christiansen, and the other Perl gods):

• Static checking: The new Perl will feature a complete type system and static checking. This checking will be as strong or as weak as you demand. This will make it's type checker as strong as C if you don't want to modify the symbol table after the fact, or as weak as nothing if you want all your checking to happen at runtime.
• Better Regexp: Regular expressions are a huge feature of Perl and have become huge features of most other languages because of Perl. Perl has raised the bar by creating a new readable regexp format that allows the creation of recursive descent grammars, in addition to plain regular expressions.
• Parrot: Perl 6 will run on top of a virtual machine named Parrot. Parrot is a VM optimized for dynamically checked languages and is decidedly different from the Java VM or the .NET CLR. It is similar to the CLR in that it allows multiple languages, C++, Java, Python, and Perl to extend and use each other's code as natively as if code were written in each its own language.
• Better Coding: They've improved the syntax and general features of objects and classes. They've improved the subroutine, methods, and functions are defined and executed. These will make Perl 6 faster and better. One of the coolest new features is that every block in Perl is a closure, so there will never again be confusion as to what value was bound to a variable when executing a subroutine. Blocks can be handed around like any other value.

Finally, I do need say something about agnosticism. Language is something akin to religion for most programmers. Typically, a programmer will try one or more languages and will become and expert and follower of one or two particular languages. Mine tend to be Perl and C++ (but I do use some Bash, Java, and C too). Unlike religion, however, I don't believe there to be a one true language. (I don't really like to make Christianity a religion, but for the sake of this argument...) I am a linguistic agnostic and believe that language preference is just that, a preference. I think all languages have value, though perhaps some are much more valuable than others. I don't assume anyone is an idiot based solely upon their language choice (though, Visual Basic programmers come close). I'd appreciate if you would give me the same courtesy. Playful jest is fine, I'd just rather not be insulted. However, (dramatically) as with being a Christian, I can accept the Perl pogroms as part of my fate—along with the insults that I'm an idiot for believing in a seven-day creation. Anyway...

Those are the major reasons (I can think of right now) that I like Perl. This isn't a real review, just my opinion. The information here was drawn from my memory, so I may have stated something wrong. In general, I think Perl is cool, but you're free to think whatever you like.