Sign In/My Account | View Cart  


AddThis Social Bookmark Button

Perl Excels at Quick Add-ons to Existing Applications

by Bonnie Allen

Not every Perl success involves a huge, complex site like Auctions. In fact, one of Perl's most successful aspects is its ability to handle small, urgent tasks that must mesh with an existing structure.

Dave Demko was a manager for the Enterprise Network Applications Documentation and Quality Assurance department when he was faced with just such a task--creating a customer response form for ENA's Web site.

ENA develops operations support systems for telecommunications providers: "the software that long-distance carriers, local phone companies, ISPs, and some power and cable companies use to design networks, establish service, monitor networks in real time, and track trouble reports," said Demko, who, true to the fast-paced world of software development, has since moved to the software consulting firm Empiric Design.

The customer response form helps customers select free white papers on the firm's various software products and helps the sales and marketing group make contact with qualified prospects.

"Because this form is a rather small application, we were told to get it done, but do it fast and with very little support," said Demko. He accomplished this task by using an existing Perl script. Knowing that Perl's speed of development, the availability of its modules, and its reliability made it a good choice for this type of server-side Web application, he searched the CPAN (Comprehensive Perl Archive Network) archives and found cgi_mailer 1.9.2, by Martin Gleeson. (This script currently resides at

Interested in learning more about Perl and other Open Source technologies? The O'Reilly Open Source Convention is the place to go.

"It didn't take long to find and evaluate Martin's package," Demko said. "It's a robust script with very good accompanying documentation. We did a fair amount of customization to make it suit our particular needs, but that customization was all the easier because we were starting from a solid, working baseline application."

Starting with the 500-line script, a single coder and some testers spent a total of about 40 hours creating or revising some 100 lines of code. "The fact that the script uses well-established modules for Internet mail handling is saving us a ton of time. This is a case of not reinventing the proverbial wheel."

"Because the write/run/debug cycle is so quick with a VHLL like Perl, one coder was able to get the script buffed up and ready to use very quickly," recalled Demko. "The standard modules are quite easy to work with. When one of our guys ran into a problem and called me at home, I flipped open the camel book, e-mailed the answer, and we were rolling once again. With Perl we can go very fast without being recklessly hasty. Even Java, with its excellent library for network-oriented applications, takes longer to write and debug."

As is the case in most of our past Perl success stories, the open source angle was pretty much a non-issue. "I know how robust, well-tested, and thoroughly supported these languages are. So I had no qualms about choosing an open source language," said Demko.

"In fact," he added, "I feel more secure in turning to something as well known and well established as Perl than I would putting all my eggs in a proprietary basket. After watching Netscape and Microsoft pick and choose which HTML and CSS standards they'll support, which ones they'll distort, and which ones they'll ignore, I have come to regard proprietary, big-vendor technology as far more capricious than open source scripting options."

Learn how large and small companies are putting Perl to work by reading more Perl Success Stories.

Nor are Demko and his coworkers dogmatic about language choice. "Like most working programmers, we're not language bigots. We use what works best for a given job," said Demko. What works includes C++, VB, Java, JavaScript and Python, depending on the requirements of the job.

"Perl works great for this server-side Web application because we know it will remain portable and because it uses well-established modules (LPW, Mail::Send, Mail:SMTP)," said Demko. "Here again you see typical Perl themes: there's more than one way to do it, so choose what works best, and go with something that's been well tested and is known to work."

Demko believes that books emphasizing how to use Perl in real-world programming situations (he kindly mentioned O'Reilly's Mastering Algorithms with Perl) will eventually convince management to move Perl into larger projects. "These are the books that go beyond how-to-hack and concentrate on how to write really good code. I think this sort of book can help add legitimacy to Perl and move the language out of the quick-&-dirty utility-scripting ghetto."

"Where the value of Perl shows up here is not in the gee-whiz factor, but the very opposite. The amount of good documentation on Perl makes this a no-big-deal, no-wasted-effort project. It's an example of Perl making easy jobs fun."