Ready, Set, Script
- By Sandra Taylor
- May 30, 2001
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.
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
(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
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,"
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.
and JScript from Netscape and Microsoft, respectively (both Netscape and Microsoft
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,
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
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.