Ok, so here's the situation. Your brand new exciting Internet company has taken off and you're selling more browsers, servers, and web applications than you ever hoped for, your company is growing by leaps and bounds, and the latest market information says that your customer base has just past the 30 million mark in less than a year.

And the only downside is that these 30 million folks might have a few problems with their browser; they might not know exactly what the Internet is; they might want to call someone for support. They might want to call *you* for technical support.

So, when this happens, you might think, "That's ok I'll just put some technical articles out on the web." But when you first look at the project, you realize that you're going to need some sort of Content Management System, some sort of Distribution system, some logging analysis, and gathering and reporting of feedback of your customers on your site. And you're going to want it yesterday.

Lucky for you, you know Perl. And with Perl you're able to get all of this built in 3 months in the spare time of 4 very busy technical support engineers.

Case 2 - A Quick and Dirty Conversion at BYTE

BYTE Magazine used to maintain its own information network and conferencing system, BIX, that both editors and readers used for exchanging ideas. The conferencing model was quite different from Usenet, somewhat closer to a mail-list. Since several of the BYTE editors were regular Usenet subscribers and preferred that model, BYTE built a gateway that translated and maintained the BIX editorial discussion groups as a private Usenet news group. The language was Perl. It took little more than a hundred lines of code and a few days of work.

Case 3 - Routing customer inquiries to appropriate experts

The performance testing group at one of the world's leading computer companies needed to automate query routing. They were directed to use their world-wide corporate Intranet, but not given any budget to do the project. Two engineers with only a few weeks of Perl experience created a solution. The Perl scripts responded to the query by matching key elements of queries with people with that expertise. The CGI programs not only pointed the client to the experts' Web-pages and E-mail addresses, but also passed the query on to all appropriate experts in their E-mail. The solution took no more than a few man-weeks and so could be asorbed into other budgets.

Case 4 - Collection and analysis of email survey data

An Internet market research firm that does its research using an E-mail survey wants to automate and generalize the handling of the anticipated ten thousand responses. Perl was used to automate the process. The Perl script generated input for SPSS, but would have been capable of doing statistical analysis if the statistician had known Perl.

Case 5 - A Cross-Platform Harness for Running Benchmarks

SPEC (the Standard Performance Evaluation Corporation), a industry consortium for benchmarking computer systems, radically changed the governing program when the SPEC92 benchmarks evolved to SPEC95. SPEC wanted to make it possible for their benchmarks to run other operating systems than UNIX without a major effort. The SPEC92 benchmarks were managed by UNIX shell scripts, unportable and inflexible. The SPEC95 benchmarks are managed by a portable, extensible engine written in Perl. The scripts take advantage of Perl's object oriented capabilities, Perl's extensibility with C, and Perl's dynamic module loading. Porting SPEC95 to Windows/NT was simple. The major problem with porting to VMS is its lack of user level forks.

Case 6 - Consultant working with Perl

Despite the years that I have spent developing in C, I have found little reason to continue to do so. Most of my work in the last ten years has been developing code that retrieves, manages, and converts information, not just data. The application programs I am involved in are merely graphical controls front-ending information retrieval, management, and conversion engines. Perl now fills the need for this kind of development better than any other language--scripting or system programming language. Even though I started using Perl merely as a glue scripting language and prototyping language, I now use it for everything. It has replaced both C and my UNIX shell programs. There will be times, I am sure, that I will have to write, or at least patch, a program in C. I expect that Java will eventually fill those requirements for me.

Cross-platform GUI interfaces are now done in HTML and run locally, in an Intranet, or as part of the Web.

Perl provides me with fast indexing to simple data structures and modules for talking to commercial databases. It provides me with system level tools for process management, file management, and interprocess communications wherever sockets are understood. It allows me to design my applications using libraries, modules, packages, and subroutines. It allows me to write applications that modify themselves; scary as that may seem, it is sometimes necessary.

The greatest benefit of Perl to me is that I can build solutions to complex problems in a fifth the time. This appeals to managers and clients, but particularly to the people paying the bills.

Case 7 - Perl as a Rapid-Prototyping Language for Flight Data Analysis
Phil Brown, Mitre Corporation Center for Advanced Aviation System Development (CAASD) (philsie@crete.mitre.org)

Because of its robustness and flexibility, Perl has become the language of choice by many programmers in CAASD for developing rapid-prototypes of concepts being explored. The Traffic Flow Management Lab (T-Lab) has implemented hundred of Perl programs that range from simple data parsing and generating plots, to measuring the complexity of regions of airspace and calculating the transit times of aircraft over these regions. The size of these applications range from about 10 lines to over 1200. Because many of the applications are very I/O intensive, Perl became the natural choice with its many parsing and searching features.

Case 8 - Online Specialty Printing
Dave Hodson (dave@iprint.com)

The iPrint Discount Printing & CyberStationery Shop (http://www.iPrint.com) is powered by a WYSIWYG, desktop publishing application on the Internet directly connected into a backend printer and sits on top of a sophisticated, real-time, multi-attributed product and pricing database technology. Customers come to our site to create, proof, and order customized popularly printed items--business cards, stationery, labels, stamps, specialty advertising items, etc online.

The iPrint system includes both a front-end (the website) and a back-end process that eliminates nearly all of the manual pre-flight process that printers perform and also provides all pertinent information to iPrint's accounting system. 95% of the approximately 80,000 lines of code used to perform this work is done using Perl v 5.003 with WinNT 4.0 OS. iPrint relies heavily on RDBMS (SQL Server) with all database interaction being performed by Perl and ODBC. iPrint uses many modules from the CPAN archives, including MIME and Win32::ODBC.

Case 9 - The Amazon.com Editorial Production System
Chris Mealy (mookie@amazon.com)

Amazon.com used Perl to develop a CGI-based editorial production system that integrates authoring (with Microsoft Word or Emacs), maintenance (version control with CVS and searching with glimpse), and output (with in-house SGML tools).

Writers use the CGI application to start an SGML document. They fill out a short form and then it generates a partially completed SGML document in the user's home directory, which may be mounted on their Microsoft Windows PC. The writer then uses their favorite editor to finish the document. With the CGI application, users see changes ('cvs diff') and their SGML rendered as HTML before submitting their document ('cvs commit'). Writers can do keyword searches of the SGML repository (by way of glimpse) and track changes ('cvs log'). Editors can also schedule content with the CGI application.

Amazon.com created a base SGML renderer class that is sub-classed to render different sections of the web site in different modes (html with graphics and html without graphics, and in the future, PointCast, XML, braille, etc).

All of the code is in Perl. It uses the CGI and HTML::Parser modules.

Case 10 - Specialty Print Servers at a New England Hospital

A major New England hospital uses twelve operating systems, from mainframes to desktop PCs. It has seven different network protocols. There are roughly twenty thousand PC workstations and two thousand printers of one type and one thousand speciality printers. The network is spread over an entire city using microwave, T1, T3, and private optical fiber. The problem is network printing. Specialty printers are required because the patient registration and billing system runs on IBM and Digital mainframes, the output going through their proprietary networks. The goal is to have all of the operating systems able to print to a standard printer through a standard protocol.

A search for appropriate scalable printer servers uncovered the MIT Project Athena's Palladium as a good starting point. However, its model of standalone print servers didn't fit. The hospital needed a distributed server model. When a two month effort to port Palladium to the hospital platform so that we could make the changes proved that it was not going to be economical, we decided to build exactly what we wanted in fast prototyping languages: Perl for the core application and Tcl/Tk for the GUI administrative interface. Palladium represents 30,000 lines of C. The more complex distributed server model required only 5,000 lines of Perl and only four man-months to achieve a first release. The Perl proved sufficiently fast on a 60MHz Pentium running a UNIX variant that no code required rewriting in C.

Case 11 - The Purdue University Network-Computing Hub
(Nirav H. Kapadia, Mark S. Lundstrom, Jose' A. B. Fortes)

In the future, computing may operate on a network-based and service-oriented model much like today's electricity and telecommunications infrastructures. This vision requires an underlying infrastructure capable of accessing and using network-accessible software and hardware resources as and when required. To address this need, we have developed a network-based virtual laboratory ("The Hub") that allows users to access and run existing software tools via standard world-wide web (WWW) browsers such as Netscape.

The Hub, a WWW-accessible collection of simulation tools and related information, is a highly modular software system that consists of approximately 12,000 lines of Perl5 code. It has been designed to: a) have a universally-accessible user-interface (via WWW browsers), b) provide access-control (security and privacy) and job-control (run, abort, and program status functions), and c) support logical (virtual) resource-organization and management. The Hub allows users to: a) upload and manipulate input-files, b) run programs, and c) view and download output - all via standard WWW browsers. The infrastructure is a distributed entity that consists of a set of specialized servers (written in Perl5) which access and control local and remote hardware and software resources. Hardware resources include arbitrary platforms, and software resources include any program (the current implementation does not support interactive and GUI-based programs).

The Hub allows tools to be organized and cross-referenced according to their domain. Resources can be added incrementally using a resource-description language specifically designed to facilitate the specification of tool and machine characteristics. For example, a new machine can be incorporated into the Hub simply by specifying its architecture (make, model, operating system, etc.) and starting a server on the machine. Similarly, a new tool can be added by "telling" the Hub the tool's location, its input behavior (e.g., command-line arguments), what kinds of machines it can run on (e.g., Sparc5), and how it fits into the logical organization of the Hub (e.g.,circuit simulation tool). Each of these tasks is typically accomplished in less than thirty minutes.

To facilitate this functionality, the Hub interprets the URLs differently from the standard document-oriented web servers. The structure of the URL is decoupled from that of the underlying filesystem and interpreted in a context-sensitive manner (based on user-specific state stored by the server), thus allowing virtual accounting and arbitrary access-control. The lab-engine provides the Hub with its on-demand high-performance computing capabilities. When a user requests the execution of a program, the lab-engine uses information in the user-specified input file to predict (via an artificial intelligence sub-system - also written in Perl5) the resources required for the run, selects an appropriate platform (e.g., workstation for a 2-D problem, supercomputer for a 3-D problem), transfers relevant input files to the selected machine, and initiates the program (via the remote server). When the run is completed, the remote server notifies the lab-engine, which retrieves the output files and informs the user.

The initial prototype, the Semiconductor Simulation Hub, currently contains thirteen semiconductor technology tools from four universities. In less than one year, over 250 users have performed more than 13,000 simulations. New Hubs for VLSI design, computer architectures, and parallel programming have been added in recent months; they currently contain a modest complement of fourteen tools. These Hubs are currently being used in several undergraduate and graduate courses at Purdue as well as to facilitate collaborative research. Regular user include students at Purdue University and researchers at several locations in the U.S. and Europe.