flag of the United Kingdom

Perl Development Environment

Date:  17th August, 2004prevnext

"A craftsman is only as good as his tools," claims the familiar adage. Of course, it depends on how you define "good".

In the field of computer programming, "good" could refer to the quality of the programmer's code, or it could refer to that same programmer's productivity.

If we are describing the quality of code, then it's arguable that the programmer's tools are irrelevant - a "good" programmer will be able to produce the same quality of code using "NotePad" as he would using "XEmacs" or even the most fully-featured integrated development environment (IDE).

However, if we define "good" as being a measure of a programmer's productivity, then there's no doubt that the right tools can make all the difference. A programmer using only NotePad is unlikely to be as productive as a programmer using a specialised IDE.

I have been programming with Perl for many years. During this time, I have tried a plethora of tools to aid in program development. Along the way, many of these tools have been discarded, leaving me with a small collection that constitutes, for myself at least, the "best of breed" Perl Development Environment...

“a craftsman is only as good as his tools”

The Editor

The principle component of my Perl Development Environment is the editor. For several years I relied on TextPad, which continues to be a powerful, general purpose editor for plain text files (source code). TextPad is still my favourite editor for plain text (it's vastly superior to NotePad), but I haven't used it for program development for some time - not since I discovered ActiveState's Komodo.

Komodo is an "award-winning, professional IDE for dynamic languages" (currently supporting Perl, PHP, Python, Tcl and XSLT). The IDE is absolutely loaded with features, a few of which were significant enough to convince me to switch from TextPad:

  • Syntax checking and colouring - While TextPad features syntax colouring, it has no facility for syntax checking. Komodo, on the other hand, performs syntax checking in real-time! This feature alone has increased my productivity tremendously, particularly during debugging sessions. The editor highlights erroneous code upon detection. This is usually enough to enable one to see the error and fix it. In the case of the more obtuse bug, a mouseover will pop-up an error message from the integrated Perl interpreter. There is also a powerful, graphical debugger with the usual options for stepping, breakpoints, watched variables, etc.
  • Folding - Some programmers don't like code-folding, but I am lost without it. Being able to selectively fold (or hide) blocks of code, sub-routines and inline documentation is especially useful when one is trying to visualise a program's overal structure, without the "noise".
  • Code Snippets - A persistent library of frequently used code blocks.
  • Code Analysis - Enables fast location and "jump to" of code elements, including modules, classes, functions and namespaces.
  • RegEx Toolkit - Perl enjoys one of the most sophisticated RegEx engines available. Unfortunately, with extreme power comes extreme complexity. Komodo's RegEx Toolkit assists in both the building and decoding of complicated regular expressions.

There is nothing wrong with writing code in a simple text-editor. However, if my experiences with Komodo are anything to go by, programming with a good IDE is not only more enjoyable, it's vastly more productive. If there is a better development tool for Perl on Windows, I'd like to know about it!

Version Control

Until recently, I'd always used CVS for version control with the WinCVS GUI. However, CVS (even with the GUI) is complicated and cumbersome (at least it is on Windows) and I never felt that I had truly mastered it, despite the fact that I used it religiously for several years.

I recently met with Tim Parkin of Pollenation Internet and he introduced me to Subversion and Tortoise. Subversion is "a version control system that is a compelling replacement for CVS," according to the project website. For myself, it boasts two features which justify that claim:

  • Atomic Commits - No part of a commit takes effect until the entire commit has succeeded. Revision numbers are per-commit, not per-file.
  • Directories, renames and file meta-data are versioned.

It's worth pointing out that Subversion is also much simpler to set up than CVS.

However, Subversion doesn't truly shine until it's coupled with TortoiseSVN, a GUI client with Windows shell integration. With TortoiseSVN installed, working with the source repository is an absolute no-brainer. Version control has never been this simple.

Local Application Server

I don't write desktop software. For the past seven years I have been developing web applications. My programs run on the web-server and the browser is my user-interface.

It follows then that I would write my code on my desktop PC, upload it onto the web-server, then fire up my browser to test it. Of course, if my code is flawed, I could crash the server - making every website it hosts come crashing down.

Sounds pretty ominous doesn't it? But web-application development doesn't have to be this threatening. I could run my development code in a protected "sandbox", whereby a fatal programming error would only crash my application, not the web-server itself. A more robust solution is to run multiple servers, with separate machines for development and production.

The best solution is to run a "web-server" on my desktop computer (let's call it a pseudo-web-server, since it is not accessible from the Internet). WIth a local application server I can try out new code with impunity, if my program crashes then my computer is the only one that is affected.

This is the route I chose then. I have a complete web application server running on each development workstation. This consists of the Apache web-server, the Perl interpreter, the MySQL RDBMS and the plethora of Perl and Apache modules (libraries) that my applications employ.

I can run my applications, via the browser, by visiting: "devel.urbanmainframe.com", "localhost" or "" and they run exactly the same as if they were on a production server, except they're a lot quicker!

The Shell

The oft-maligned shell is a critical component of my development environment. I use the shell to compile modules, access the CPAN (with the PPM), browse documentation and to control the Apache server

The shell is also my principle interface to MySQL. There are several GUIs for MySQL but I still haven't found one that is more efficient, or as quick as MySQL's interactive shell.

FInal Words

These then are the principle components of my Perl Programming Environment, the tools I spend an inordinate amount of time working with.

Obviously, productive programming requires more than just great development tools. At least as much attention should be paid to the programmer's physical environment as to his digital one. I recommend you read some of Paul Graham's essays (especially "Great Hackers") along with a selection of Joel Spolsky's (Joel's "Bionic Office" is a good place to start), both authors discuss the programmer's workplace in great detail.

You can comment on this entry, or read what others have written (10 comments).