In-Depth

Ready, Set, Script

Chances are, if there is Unix in your shop, you are already using it. If you happen to work in a Microsoft shop, you will soon be using it (if not already). And if you are in a mainframe shop, don't think for a moment that you are immune to it.

"It" is a scripting language. And "it" may well change the way you develop, assemble and/or administer your applications.

While it may amaze those who have just discovered JavaScript, scripting languages are not new. They come in a remarkable variety of flavors, with most of today's popular ones tracing their genealogy back to Unix roots -- awk, Bourne shell (sh), Bourne Again Shell (bash), C Shell (csh), grep, Korn shell (ksh), Lingo, Perl, Python, Rexx, Scheme, sed and SWIG. The underlying nature of these languages set the basic tenets for their continuing evolution, as well as for a new crop of offerings that include languages like JavaScript, JScript, Tool Command Language (Tcl) and VBScript. No matter what the scripting language, they all share a singular characteristic: They are optimized for the people using the computer, not for the computer. They are easy-to-learn, easy-to-use and allow users to automate some aspect of system operation.

With the more traditional scripting languages, such as Unix shell scripts, users were often system managers, the domain was system administration and the activities involved automating system processes: validating user passwords, automatically starting processes, and checking system status such as disk space and so on. So what is the common thread between system man- agement scripting tools and the new genre of scripting languages?

The short answer is the deliberate absence of the baggage normally associated with application development. There are no complex development languages with long learning curves. No long development cycles. From the mature scripting language to the newest kid on the block, the design center for these languages is the domain-savvy user. As such, scripting environments are generally interpretive, and code-and-go is the modus operandi. Scripting languages have not always been pretty, but they wore the mantle of rapid application development (RAD) before RAD was, well, rad.

Languages are not static, and that includes scripting languages. From the very early days of brute-force macros and automating straightforward system commands, scripting languages began accumulating all sorts of functionality and sophistication -- the ability to specify variables, to perform comparative operations, and to implement decision and control loops, for example.

The czars of script also took the technology into specialized territory. The most well-known of these is probably Larry Wall with Perl, a freeware scripting language with top-notch credentials for its ability to seek out, retrieve and manipulate all ilk of text-based data. When Wall added support for CGI, Perl became a virtual mainstay to those moving into the new world of text-oriented, Web-enabled systems.

Despite their pervasiveness, scripting languages have garnered the reputation of not being "real" languages. Even Fra-mingham, Mass.-based International Data Corp., the industry's unofficial market share score keeper, does not track this language class. In part, this stems from the technology's traditional ties to system management and not the business of the business. While this was true of the early iterations, scripting languages have gradually inched their way into some very critical applications.

While the "easy-to-learn and easy-to-use" mantra of newer scripting languages such as JavaScript, JScript, Tcl and VBScript has not changed, their unit of automation has. Instead of processes and programs in the context of a system management environment, we now see a generation of scripting languages focused squarely on automating new development paradigms --components and objects that frequently, but do not necessarily, live in a 'Net-enabled environment. (Note that we use the terms object and component interchangeably.) The measure of these New Age languages is their ability to easily wire together (integrate) objects from a potentially wide range of sources. These can be the classic C and C++ objects developed by a company's own technical gurus; objects developed by domain experts using the scripting language itself; objects from a third party; objects available in the underlying system environment, such as GUI and middleware objects; or all of the above.

One company long past the discussion stage and well into implementation is Cisco Systems Inc., San Jose, Calif. Cisco's reputation for quality is not accidental. "Cisco has invested heavily in quality," said Jay Yang, manager of Cisco's Automated Test Solutions group. "And the investment is not just in tools. It's tools and people and some pretty disciplined process. Before any public announcement, we've tested -- and I mean beat on -- each product's functionality, reliability and performance using our Automated Test System [ATS], a homegrown testing system based on the Tcl scripting language."

This may sound like traditional quality assurance (QA), but it is QA with a Cisco twist. "I manage a central tools group. But I deliver the tools to other internal groups -- the different product groups -- for use in the testing process," explained Yang.

According to Yang, "Cisco's distributed organizational structure was one of the things that made Tcl so appealing. Tcl has a short learning curve, and it's especially easy to extend. When product groups have a special testing need, they don't need to run back to us for implementation. Most of the time, they can script the test themselves. It's important for the groups to have that flexibility and ability to act quickly."

As most survivors will attest, successfully managing any type of central IT group today is not easy. However, Yang has found an especially workable combination of collaborative practices and products. "We decided to go with Tcl more than five years ago, and have used it ever since. But I still encourage my group, and the product groups, to keep looking into the market to see what else is out there," said Yang.

Standards and responsibility

Most scripting languages fall into the freeware category -- a communal approach to requirement specification and bug fixing. The evolution of these languages truly reflects the needs of the user community, not corporate egos or marketing maneuvers. Still, for the increasing number of companies using scripting in critical business applications, it is unnerving to deal with this communal mentality. For better or worse, corporations are used to responsibility and accountability from the vendors that supply their critical development tools.

The new generation of scripting tools offers this support. There is JavaScript and JScript from Netscape and Microsoft, respectively (both Netscape and Microsoft have agreed to implement a standardized version of JavaScript developed by the European Computer Manufacturers' Association). There is VBScript, also from Microsoft. For its part, Tcl, while still an open source language, now has a formal development environment, as well as structured support options available from Palo Alto, Calif.-based Scriptics Corp. Thus, we are even seeing vestiges of capitalism creeping into the traditional freeware space.

Scripting and the 'Net

Scripting and object integration are emerging companions. Most of the attention, however, has been focused on scripting and objects in the context of the Web. Dave Wascha, scripting product manager at Microsoft, sees the Web as a major driver behind the interest in scripting. "We see two types of users. There are still the IT administrators, but there's a definite rise in the number of queries for Web development," said Wascha. "The hits per month on Microsoft's scripting site [www.msdn.microsoft.com/scripting/] has recently, and in some instances, exceeded those on the Visual Studio site."

Scripting has been described as the poor man's Dynamic HTML (DHTML). Scripting text, embedded within HTML text, provides a mechanism for breathing life into an otherwise static page. Here, the browser is the script interpreter. And that browser must be script-enabled, in other words, configured with the appropriate interpreter. A browser that supports the downloading of Java applets does not automatically support scripting. A browser that supports Version x.x of, for example, Netscape's JavaScript, does not necessarily support Version y.y of Microsoft's JScript.

There are other major attractions for client-side scripting. Scripts operating on a client can easily validate user input -- on the client and without the need to incur the network traffic and overhead involved in sending the input back to a server for processing. A scriptwriter can also manipulate "cookies" in applications such as the now-prevalent shopping cart mode of ordering. Additionally, scriptwriters can access back-end databases without the assistance of CGI.

Project Cool Inc.

Founded in 1995, Project Cool Inc. is a privately funded California firm that has established an educational and resource center for Web builders. Its Web site receives more than 2.5 million page views a month.

Glenn Davis, creator of "Cool Site of the Day," is Project Cool's co-founder and CTO. Davis is a combination of Web critic, evangelist, advocate, teacher and watchdog. He is also not without influence. The evening of my talk with Davis, he and two other industry consciences were hosting an open forum with the hottest seats in the house reserved for Microsoft and Netscape. The subject? Adherence to browser standards.

Davis sees the huge potential in the Web, not only for mega-companies, but also for small businesses and even individuals. He believes scripting offers the most viable solution to tapping into that potential. However, it needs to be intelligent scripting. In much the same way as corporate developers envision libraries of components that can be used and reused as needed, Davis envisions libraries of scripts that can be used and/or modified as needed.

For this approach to work, browser standards are critical. Without the consistent base provided by standards-based browsers, Web developers will spend their time customizing pages for each browser's idiosyncrasies, or be reduced to a least-common-denominator approach to Web design.

Just a matter of time?

Scripting languages are far from "no brainers," and IT firms incorporating a scripting language need to evaluate the risks and benefits in light of the function they are trying to accomplish. A systems administration tool? An object integration facility? A Web page enhancer? Scripting can play, and play effectively, in all of these spaces. But there are risks.

Scripting is hot, and IT firms must be prepared to face the fast-changing technology and incompatibilities that must surely follow. The number of options is also increasing, with choices seeming to multiply on a weekly basis. And within the scripting community itself, proponents continue to debate the merits of specific languages. With the exception of a few corporate-backed languages, scripting languages are often the brainchild of a single individual. What happens when the language creator retires?

Finally, and we believe the most critical risk, is the similarity between the appeal of scripting languages today and the earlier appeal of client/server RAD tools. Those RAD tools promoted development without forethought, and ultimately created a generation of ready-fire-aim applications. While the use of scripting languages is not yet so pervasive, the danger is there.

Issues aside, the growing popularity of these languages indicate a need that is more pressing than ever. In smaller shops, the need is access to computing power by employees that do not have a degree in computer science. In larger firms, it is about collaborative empowerment and a distribution of work across diverse technical and domain-oriented communities. Today's scripting languages provide an increasingly viable way to address those needs.

Most   Popular