F0018-9162/98/$10.00 © 1998 IEEE March 1998 23

Scripting: Higher-Level Programmingfor the 21st Century

or the past 15 years, a fundamental change has beenoccurring in the way people write computer programs.The change is a transition from system programminglanguages such as C or C++ to scripting languages suchas Perl or Tcl. Although many people are participat-ing in the change, few realize that the change is occur-ring and even fewer know why it is happening. Thisarticle explains why scripting languages will handlemany of the programming tasks in the next centurybetter than system programming languages.

Scripting languages are designed for different tasksthan are system programming languages, and thisleads to fundamental differences in the languages.System programming languages were designed forbuilding data structures and algorithms from scratch,starting from the most primitive computer elementssuch as words of memory. In contrast, scripting lan-guages are designed for gluing: They assume the exis-tence of a set of powerful components and areintended primarily for connecting components. Systemprogramming languages are strongly typed to helpmanage complexity, while scripting languages are type-less to simplify connections among components andprovide rapid application development.

Scripting languages and system programming lan-guages are complementary, and most major comput-ing platforms since the 1960s have included both kindsof languages. The languages are typically used togetherin component frameworks, where components are cre-

ated with system programming languages and gluedtogether with scripting languages. However, severalrecent trends, such as faster machines, better script-ing languages, the increasing importance of graphicaluser interfaces (GUIs) and component architectures,and the growth of the Internet, have greatly expandedthe applicability of scripting languages. These trendswill continue over the next decade, with more andmore new applications written entirely in scriptinglanguages and system programming languages usedprimarily for creating components.

SYSTEM PROGRAMMING LANGUAGESTo understand the differences between scripting lan-

guages and system programming languages, it isimportant to understand how system programminglanguages evolved. System programming languageswere introduced as an alternative to assembly lan-guages. In assembly languages, virtually every aspectof the machine is reflected in the program. Each state-ment represents a single machine instruction and pro-grammers must deal with low-level details such asregister allocation and procedure-calling sequences.As a result, it is difficult to write and maintain largeprograms in assembly languages.

By the late 1950s, higher-level languages such asLisp, Fortran, and Algol began to appear. In these lan-guages, statements no longer correspond exactly tomachine instructions; a compiler translates each state-

Cybe

rsqu

are

Increases in computer speed and changes in theapplication mix are making scripting languages

more and more important for the applications of thefuture. Scripting languages differ from system

programming languages in that they are designed for“gluing” applications together. They use typeless

approaches to achieve a higher level of programmingand more rapid application development than

system programming languages.

John K. OusterhoutSun Microsystems Laboratories

.

24 Computer

ment in the source program into a sequence ofbinary instructions. Over time a series of sys-tem programming languages evolved fromAlgol, including PL/1, Pascal, C, C++, and Java.System programming languages are less efficientthan assembly languages but they allow appli-cations to be developed much more quickly. Asa result, system programming languages havealmost completely replaced assembly languagesfor the development of large applications.

Higher-level languagesSystem programming languages differ from

assembly languages in two ways: they are higherlevel and they are strongly typed. The term“higher level” means that many details are han-dled automatically, so programmers can write

less code to get the same job done. For example:

• Register allocation is handled by the compiler sothat programmers need not write code to moveinformation between registers and memory.

• Procedure calling sequences are generated auto-matically; programmers need not worry aboutmoving arguments to and from the call stack.

• Programmers can use simple keywords such aswhile and if for control structures; the com-piler generates all the detailed instructions toimplement the control structures.

On average, each line of code in a system pro-gramming language translates to about five machineinstructions, compared with one instruction per line inan assembly program. (In an informal analysis of eightC files written by five different people, I found that theratio ranged from three to seven instructions per line;1

in a study of numerous languages, Capers Jones foundthat, for a given task, assembly languages require threeto six times as many lines of code as system program-ming languages.2) Programmers can write roughly thesame number of lines of code per year regardless oflanguage,3 so system programming languages allowapplications to be written much more quickly thanassembly languages.

TypingThe second difference between assembly languages

and system programming languages is typing. I usethe term typing to refer to the degree to which themeaning of information is specified in advance of itsuse. In a strongly typed language, the programmerdeclares how each piece of information will be used,and the language prevents the information from beingused in any other way. In a weakly typed language,there are no a priori restrictions on how informationcan be used; the meaning of information is determined

solely by the way it is used, not by any initial promises.Modern computers are fundamentally typeless. Any

word in memory can hold any kind of value, such asan integer, a floating-point number, a pointer, or aninstruction. The meaning of a value is determined byhow it is used. If the program counter points at a wordof memory then it is treated as an instruction; if a wordis referenced by an integer add instruction, then it istreated as an integer; and so on. The same word canbe used in different ways at different times.

In contrast, today’s system programming languagesare strongly typed. For example:

• Each variable in a system programming languagemust be declared with a particular type such asinteger or pointer to string, and it must be usedin ways that are appropriate for the type.

• Data and code are segregated; it is difficult if notimpossible to create new code on the fly.

• Variables can be collected into structures orobjects with well-defined substructure and pro-cedures or methods to manipulate them. Anobject of one type cannot be used where an objectof a different type is expected.

Typing has several advantages. First, it makes largeprograms more manageable by clarifying how thingsare used and differentiating among things that must betreated differently. Second, compilers use type infor-mation to detect certain kinds of errors, such as anattempt to use a floating-point value as a pointer.Third, typing improves performance by allowing com-pilers to generate specialized code. For example, if acompiler knows that a variable always holds an inte-ger value, then it can generate integer instructions tomanipulate the variable; if the compiler does not knowthe type of a variable, then it must generate additionalinstructions to check the variable’s type at runtime.

Figure 1 compares a variety of languages on thebasis of their level of programming and strength oftyping.

SCRIPTING LANGUAGESScripting languages such as Perl,4 Python,5 Rexx,6

Tcl,7 Visual Basic, and the Unix shells represent a verydifferent style of programming than do system pro-gramming languages. Scripting languages assume thata collection of useful components already exist in otherlanguages. They are intended not for writing applica-tions from scratch but rather for combining compo-nents. For example, Tcl and Visual Basic can be usedto arrange collections of user interface controls on thescreen, and Unix shell scripts are used to assemble fil-ter programs into pipelines. Scripting languages areoften used to extend the features of components; how-ever, they are rarely used for complex algorithms and

Scripting languagesassume that a

collection of usefulcomponents already

exist in otherlanguages. They are

intended not for writing applications

from scratch butrather for combining

components.

.

data structures, which are usually provided by the com-ponents. Scripting languages are sometimes referred toas glue languages or system integration languages.

Scripting languages are generally typelessTo simplify the task of connecting components,

scripting languages tend to be typeless. All things lookand behave the same so that they are interchangeable.For example, in Tcl or Visual Basic a variable can holda string one moment and an integer the next. Codeand data are often interchangeable, so that a programcan write another program and then execute it on thefly. Scripting languages are often string-oriented, asthis provides a uniform representation for many dif-ferent things.

A typeless language makes it much easier to hooktogether components. There are no a priori restrictionson how things can be used, and all components andvalues are represented in a uniform fashion. Thus anycomponent or value can be used in any situation; com-ponents designed for one purpose can be used fortotally different purposes never foreseen by thedesigner. For example, in the Unix shells all filter pro-grams read a stream of bytes from an input and writea stream of bytes to an output. Any two programs canbe connected by attaching the output of one programto the input of the other. The following shell commandstacks three filters together to count the number of linesin the selection that contain the word “scripting”:

select | grep scripting | wc

The select program reads the text that is currentlyselected on the display and prints the text on its out-put; the grep program reads its input and prints onits output the lines containing “scripting”; the wc pro-gram counts the number of lines on its input. Each ofthese programs can be used in numerous other situa-tions to perform different tasks.

The strongly typed nature of system programminglanguages discourages reuse. It encourages program-mers to create a variety of incompatible interfaces, eachof which requires objects of specific types. The com-piler prevents any other types of objects from beingused with the interface, even if that would be useful. Soto use a new object with an existing interface, the pro-grammer must write conversion code to translatebetween the type of the object and the type expected bythe interface. This in turn requires recompiling part orall of the application; many applications today are dis-tributed in binary form so this is not possible.

To appreciate the advantages of a typeless language,consider the following Tcl command:

button .b -text Hello! -font {Times 16} -command {puts hello}

This command creates a new button control that dis-plays a text string in a 16-point Times font and printsa short message when the user clicks on the control.The command mixes six different types of things in asingle statement: a command name (button), a but-ton control (.b), property names (-text, -font, and-command), simple strings (Hello! and hello), afont name (Times 16) that includes a typeface name(Times) and a size in points (16), and a Tcl script(puts hello). Tcl represents all of these things uni-formly with strings. In this example, the propertiescan be specified in any order and unspecified proper-ties are given default values; more than 20 propertieswere left unspecified in the example.

The same example requires seven lines of code intwo methods when implemented in Java. With C++and Microsoft Foundation Classes (MFC), it requiresabout 25 lines of code in three procedures.1 Just set-ting the font requires several lines of code in MFC:

CFont *fontPtr = new CFont();fontPtr->CreateFont(16, 0, 0, 0, 700,

0, 0, 0, ANSI_CHARSET, OUT_DEFAULT_PRECIS,CLIP_DEFAULT_PRECIS, DEFAULT_QUALITY,DEFAULT_PITCH|FF_DONTCARE, “Times New Roman”);

buttonPtr->SetFont(fontPtr);

Much of this code is a consequence of the strong typ-ing. To set the font of a button, its SetFont methodmust be invoked, but this method must be passed apointer to a CFont object. This in turn requires a newobject to be declared and initialized. To initialize theCFont object its CreateFont method must be

March 1998 25

Tcl/Perl

Visual Basic

Scripting

C

C++Java

System programming

StrongDegree of typing

None

Assembly

Inst

ruct

ion/

stat

emen

t

1,000

100

10

1

Figure 1. A compari-son of variousprogramminglanguages based ontheir level (higher-level languages exe-cute more machineinstructions for eachlanguage statement)and their degree oftyping. System pro-gramming languagessuch as C tend to bestrongly typed andmedium level (five to10 instructions perstatement). Scriptinglanguages such as Tcltend to be weaklytyped and very highlevel (100 to1,000instructions per state-ment).

.

26 Computer

invoked, but CreateFont has a rigid interfacethat requires 14 different arguments to be spec-ified. In Tcl, the essential characteristics of thefont (typeface Times, size 16 points) can be usedimmediately with no declarations or conversions.Furthermore, Tcl allows the button’s behaviorto be included directly in the command that cre-ates the button, while C++ and Java require it tobe placed in a separately declared method.(In practice, a trivial example like this would

probably be handled with a graphical develop-ment environment that hides the complexity ofthe underlying language. The user enters prop-erty values in a form and the development envi-ronment outputs the code. However, in morecomplex situations, such as conditional assign-

ment of property values or interfaces generated pro-grammatically, the developer must write code in theunderlying language.)

It might seem that the typeless nature of scripting lan-guages could allow errors to go undetected, but in prac-tice scripting languages are just as safe as systemprogramming languages. For example, an error willoccur if the font size specified for the button exampleabove is a noninteger string such as xyz. Scripting lan-guages do their error checking at the last possiblemoment, when a value is used. Strong typing allowserrors to be detected at compile time, so the cost of run-time checks is avoided. However, the price to be paidfor efficiency is restrictions on how information can beused; this results in more code and less flexible programs.

Scripting languages are interpretedAnother key difference between scripting languages

and system programming languages is that scripting lan-guages are usually interpreted, whereas system pro-gramming languages are usually compiled. Interpretedlanguages provide rapid turnaround during developmentby eliminating compile times. Interpreters also makeapplications more flexible by allowing users to programthe applications at runtime. For example, many synthe-sis and analysis tools for integrated circuits include a Tclinterpreter; users of the programs write Tcl scripts tospecify their designs and control the operation of thetools. Interpreters also allow powerful effects to beachieved by generating code on the fly. For example, aTcl-based Web browser can parse a Web page by trans-lating the HTML for the page into a Tcl script using afew regular expression substitutions. It then executes theTcl script to render the page on the screen.

Scripting languages are less efficient than system pro-gramming languages, in part because they use inter-preters instead of compilers but also because their basiccomponents are chosen for power and ease of use ratherthan an efficient mapping onto the underlying hardware.For example, scripting languages often use variable-

length strings in situations where a system programminglanguage would use a binary value that fits in a singlemachine word, and they use hash tables where systemprogramming languages use indexed arrays.

Fortunately, the performance of a scripting languageis not usually a major issue. Applications for scriptinglanguages are generally smaller than applications forsystem programming languages, and the performanceof a scripting application tends to be dominated by theperformance of the components, which are typicallyimplemented in a system programming language.

Scripting languages are higher level than system pro-gramming languages in the sense that a single state-ment does more work on average. A typical statementin a scripting language executes hundreds or thou-sands of machine instructions, whereas a typical state-ment in a system programming language executesabout five machine instructions (as Figure 1 illus-trates). Part of this difference is because scripting lan-guages use interpreters, but much of the difference isbecause the primitive operations in scripting languageshave greater functionality. For example, in Perl it isabout as easy to invoke a regular expression substitu-tion as it is to invoke an integer addition. In Tcl, avariable can have traces associated with it so that set-ting the variable causes side effects; for example, atrace might be used to keep the variable’s valueupdated continuously on the screen.

Scripting languages allow rapid development of glu-ing-oriented applications. Table 1 provides anecdotalsupport for this claim. It describes several applicationsthat were implemented in a system programming lan-guage and then reimplemented in a scripting languageor vice versa. In every case, the scripting versionrequired less code and development time than the sys-tem programming version; the difference varied froma factor of two to a factor of 60. Scripting languagesprovided less benefit when they were used for the firstimplementation; this suggests that any reimplementa-tion benefits substantially from the experiences of thefirst implementation and that the true differencebetween scripting and system programming is morelike a factor of five to 10, rather than the extremepoints of the table. The benefits of scripting alsodepend on the application. In the last example in Table1, the GUI part of the application is gluing-orientedbut the simulator part is not; this might explain whythe application benefited less from scripting than otherapplications.

The information in the table was provided by vari-ous Tcl developers in response to an article posted onthe comp.lang.tcl newsgroup.1

DIFFERENT TOOLS FOR DIFFERENT TASKSA scripting language is not a replacement for a sys-

tem programming language or vice versa. Each is

It might seem thatthe typeless nature ofscripting languagescould allow errors to

go undetected, but inpractice scripting

languages are just assafe as systemprogramming

languages.

.

suited to a different set of tasks. For gluing and systemintegration, applications can be developed five to 10times faster with a scripting language; system pro-gramming languages require large amounts of boiler-plate and conversion code to connect the pieces,whereas this can be done directly with a scripting lan-guage. For complex algorithms and data structures,the strong typing of a system programming languagemakes programs easier to manage. Where executionspeed is key, a system programming language canoften run 10 to 20 times faster than a scripting lan-guage because it makes fewer runtime checks.

In deciding whether to use a scripting language ora system programming language for a particular task,consider the following questions:

• Is the application’s main task to connect preex-isting components?

• Will the application manipulate a variety of dif-ferent things?

• Does the application include a GUI?• Does the application do a lot of string manipulation?• Will the application’s functions evolve rapidly

over time?• Does the application need to be extensible?

Affirmative answers to these questions suggest thata scripting language will work well for the applica-

tion. On the other hand, affirmative answers to thefollowing questions suggest that an application is bet-ter suited to a system programming language:

• Does the application implement complex algo-rithms or data structures?

• Does the application manipulate large datasets,for example, all the pixels in an image, such thatexecution speed is critical?

• Are the application’s functions well defined andslow to change?

Most of the major computing platforms over thepast 30 years have provided both system program-ming and scripting languages. For example, one of thefirst scripting languages, albeit a crude one, was JobControl Language (JCL), which was used to sequencejob steps in OS/360. The individual job steps werewritten in PL/1, Fortran, or assembler languages,which were the system programming languages of theday. In the Unix machines of the 1980s, C was used forsystem programming and shell programs such as shand csh for scripting. In the PC world of the 1990s,C and C++ are used for system programming andVisual Basic for scripting. In the Internet world that istaking shape now, Java is used for system program-ming and languages such as JavaScript, Perl, and Tclare used for scripting.

March 1998 27

Table 1. Comparing applications implemented in both system programming languages and scripting languages.

Application (contributor) Comparison Code ratio* Effort ratio** Comments

Database application C++ version: 2 months 60 C++ version (Ken Corey) Tcl version: 1 day implemented first; Tcl version

had more functionalityComputer system test and installation C test application: 47 22 C version implemented first;(Andy Belsey) 272,000 lines, 120 months Tcl/Perl version replaced both

C FIS application: 90,000 lines, C applications60 months

Tcl/Perl version: 7,700 lines,8 months

Database library C++ version: 2-3 months 8-12 C++ version implemented first(Ken Corey) Tcl version: 1 weekSecurity scanner C version: 3,000 lines 10 C version implemented first; (Jim Graham) Tcl version: 300 lines Tcl version had more functionalityDisplay oil well production curves C version: 3 months 6 Tcl version implemented first(Dan Schenck) Tcl version: 2 weeksQuery dispatcher C version: 1,200 lines, 4-8 weeks 2.5 4-8 C version implemented first,(Paul Healy) Tcl version: 500 lines, 1 week uncommented; Tcl version had

comments, more functionalitySpreadsheet tool C version: 1,460 lines 4 Tcl version implemented first

Tcl version: 380 linesSimulator and GUI Java version: 3,400 lines, 3-4 weeks 2 3-4 Tcl version had 10 to 20 percent(Randy Wang) Tcl version: 1,600 lines, <1 week more functionality and was

implemented first

* Code ratio is the ratio of lines of code for the two implementations (<1 means the system programming language required more lines).** Effort ratio is the ratio of development times. In most cases the two versions were implemented by different people.

.

28 Computer

Scripting and system programming are sym-biotic. Used together, they produce program-ming environments of exceptional power.System programming languages are used to cre-ate exciting components that can then be assem-bled using scripting languages. For example,much of the attraction of Visual Basic is thatsystem programmers can write ActiveX com-ponents in C and less sophisticated program-mers can then use the components in VisualBasic applications. In Unix it is easy to writeshell scripts that invoke applications written inC. One of the reasons for the popularity of Tcl

is the ability to extend the language by writing C codethat implements new commands.

SCRIPTING IS ON THE RISEScripting languages have existed for a long time, but

in recent years several factors have combined toincrease their importance. The most important factoris a shift in the application mix toward gluing appli-cations. Three examples of this shift are GUIs, theInternet, and component frameworks.

Graphical user interfacesGUIs first appeared in the early 1980s and became

widespread by the end of the decade; GUIs nowaccount for half or more of the total effort in manyprogramming projects. GUIs are fundamentally gluingapplications. The goal is not to create new function-ality but to make connections between a collection ofgraphical controls and the internal functions of theapplication.

I am not aware of any rapid-development environ-ments for GUIs based on a system programming lan-guage. Whether the environment is Windows, Mac-intosh Toolbox, or Unix Motif, GUI toolkits based onlanguages such as C or C++ have proven hard to learn,clumsy to use, and inflexible in the results they produce.Some of these systems have nice graphical tools fordesigning screen layouts that hide the underlying lan-guage, but things become difficult as soon as the designerhas to write code, for example, to provide the behav-iors for the interface elements. All of the best rapid-devel-opment GUI environments are based on scriptinglanguages: Visual Basic, HyperCard, and Tcl/Tk.

InternetThe growth of the Internet has also popularized

scripting languages. The Internet is nothing more thana gluing tool. It does not create any new computationsor data; it simply makes a huge number of existingthings easily accessible. The ideal language for mostInternet programming tasks is one that makes it pos-sible for all the connected components to worktogether; that is, a scripting language. For example,

Perl has become popular for writing CGI scripts andJavaScript is popular for scripting in Web pages.

Component frameworksThe third example of scripting-oriented applications

is component frameworks such as ActiveX and Java-Beans. Although system programming languageswork well for creating components, the task of assem-bling components into applications is better suited toscripting. Without a good scripting language tomanipulate the components, much of the power of acomponent framework is lost. This might explain inpart why component frameworks have been more suc-cessful on PCs, where Visual Basic provides a conve-nient scripting tool, than on other platforms such asUnix/CORBA, where scripting is not included in thecomponent framework.

Better scripting technologyAnother reason for the increasing popularity of

scripting languages is improvements in scripting tech-nology. Modern scripting languages such as Tcl andPerl are a far cry from early scripting languages such asJCL. For example, JCL did not even provide basic iter-ation and early Unix shells did not support procedures.Scripting technology is still relatively immature eventoday. For example, Visual Basic is not really a script-ing language; it was originally implemented as a simplesystem programming language, then modified to makeit more suitable for scripting. Future scripting languageswill be even better than those available today.

Scripting technology has also benefited from theeverincreasing speed of computer hardware. It usedto be that the only way to get acceptable performancein an application of any complexity was to use a sys-tem programming language. In some cases, even sys-tem programming languages were not efficientenough, so the applications had to be written in assem-bler. However, machines today are 100 to 500 timesfaster than the machines of 1980, and performancedoubles every 18 months. Today, many applicationscan be implemented in an interpreted language andstill have excellent performance. For example, a Tclscript can manipulate collections with several thou-sand objects and still provide good interactiveresponse. As computers get faster, scripting willbecome attractive for larger and larger applications.

Casual programmersOne final reason for the increasing use of scripting

languages is a change in the programmer community.Twenty years ago, most programmers were sophisti-cated programmers working on large projects. Pro-grammers of that era expected to spend severalmonths to master a language and its programmingenvironment, and system programming languages

Scripting and systemprogramming aresymbiotic. Used

together, theyproduce

programmingenvironments of

exceptional power.

.

were designed for such programmers. However, sincethe arrival of the PC more and more casual program-mers have joined the programmer community. Forthese people, programming is not their main job func-tion; it is a tool they use occasionally to help with theirmain job. Examples of casual programming are sim-ple database queries or macros for a spreadsheet.

Casual programmers are unwilling to spend monthslearning a system programming language, but they canoften learn enough about a scripting language in a fewhours to write useful programs. Scripting languagesare easier to learn because they have simpler syntaxthan system programming languages and they omitcomplex features like objects and threads. For exam-ple, compare Visual Basic with Visual C++; few casualprogrammers would attempt to use Visual C++, butmany have built useful applications with Visual Basic.Even today, the number of applications written in

scripting languages is much greater than the numberof applications written in system programming lan-guages. On Unix systems, there are many more shellscripts than C programs, and under Windows thereare many more Visual Basic programs and applica-tions than C or C++. Of course, most of the largestand most widely used applications are written in sys-tem programming languages, so a comparison on thebasis of total lines of code or number of installedcopies might still favor system programming lan-guages. Nonetheless, scripting languages are alreadya major force in application development and theirmarket share will increase in the future.

THE ROLE OF OBJECTSScripting languages have been mostly overlooked

by experts in programming languages and softwareengineering. Instead, the experts have focused theirattention on object-oriented system programming lan-guages such as C++ and Java. Object-oriented (OO)programming is widely believed to represent the nextmajor step in the evolution of programming lan-guages. OO features such as strong typing and inher-itance are often claimed to reduce development time,increase software reuse, and solve many other prob-lems including those addressed by scripting languages.

How much benefit has OO programming actuallyprovided? Unfortunately I have not seen enough quan-titative data to answer this question definitively. In myopinion, objects provide only a modest benefit: perhapsa 20 to 30 percent improvement in productivity but cer-tainly not a factor of two, let alone a factor of 10. C++now seems to be reviled as much as it is loved, and somelanguage experts are beginning to speak out againstOO programming.8 Objects do not improve produc-tivity in the dramatic way that scripting does, and thebenefits of OO programming can be achieved in script-ing languages.

OO programming does not provide a largeimprovement in productivity because it neitherraises the level of programming nor encouragesreuse. In an OO language such as C++, pro-grammers still work with small basic units thatmust be described and manipulated in greatdetail. In principle, powerful library packagescould be developed, and if these libraries wereused extensively they could raise the level of pro-gramming. However, few such libraries exist.The strong typing of most OO languages encour-ages narrowly defined packages that are hard toreuse. Each package requires objects of a specifictype; if two packages are to work together, con-version code must be written to translatebetween the types required by the packages.

Another problem with OO languages is theiremphasis on inheritance. Implementation inher-itance, in which one class borrows code that was writ-ten for another class, is a bad idea that makes softwareharder to manage and reuse. It binds the implementa-tions of classes together so that neither class can beunderstood without the other. A subclass cannot beunderstood without knowing how the inherited meth-ods are implemented in its superclass, and a superclasscannot be understood without knowing how its meth-ods are inherited in subclasses. In a complex class hier-archy, no individual class can be understood withoutunderstanding all the other classes in the hierarchy. Evenworse, a class cannot be separated from its hierarchyfor reuse. Multiple inheritance makes these problemseven worse. Implementation inheritance causes the sameintertwining and brittleness that have been observedwhen goto statements are overused. As a result, OOsystems often suffer from complexity and lack of reuse.

Scripting languages, on the other hand, have actu-ally generated significant software reuse. The modelthey follow is one in which interesting componentsare built in a system programming language and thenglued together into applications with a scripting lan-guage. This division of labor provides a natural frame-work for reusability. Components are designed to bereusable, and there are well-defined interfaces betweencomponents and scripts that make it easy to use com-ponents. For example, in Tcl the components are cus-tom commands implemented in C; they look just likethe built-in commands so they are easy to invoke inTcl scripts. In Visual Basic, the components areActiveX extensions, which can be used by draggingthem from a palette onto a form.

Nonetheless, OO programming does provide at leasttwo useful features. The first is encapsulation: objectscombine data and code in a way that hides implemen-tation details. This makes it easier to manage large sys-tems. The second useful feature is interface inheritance,where classes provide the same methods and applica-

March 1998 29

Implementationinheritance causes

the same intertwining and

brittleness that havebeen observed whengoto statements are

overused. As aresult, OO systemsoften suffer from

complexity and lackof reuse.

.

30 Computer

tion programming interfaces (APIs) even thoughthey have different implementations. This makesthe classes interchangeable and encourages reuse.

Fortunately, the benefits of objects can beachieved in scripting languages as well as sys-tem programming languages, and virtually allscripting languages have some support for OOprogramming. For example, Python is an OOscripting language; Perl v5 includes support forobjects; Object Rexx is an OO version of Rexx;and Incr Tcl is an OO extension to Tcl. Onedifference is that objects in scripting languagestend to be typeless, while objects in system pro-gramming languages tend to be strongly typed.

OTHER LANGUAGESThis article is not intended as a complete

characterization of all programming languages.There are many other attributes of programming lan-guages besides strength of typing and the level of pro-gramming, and there are many interesting languagesthat cannot be characterized cleanly as a system pro-gramming language or a scripting language. For exam-ple, the Lisp family of languages lies somewherebetween scripting and system programming, withsome of the attributes of each. Lisp pioneered con-cepts such as interpretation and dynamic typing thatare now common in scripting languages, as well asautomatic storage management and integrated devel-opment environments, which are now used in bothscripting and system programming languages.

S cripting languages represent a different set oftrade-offs than system programming languages.They give up execution speed and strength of typ-

ing relative to system programming languages but pro-vide significantly higher programmer productivity andsoftware reuse. This trade-off makes more and moresense as computers become faster and cheaper in com-parison to programmers. System programming lan-guages are well suited to building components wherethe complexity is in the data structures and algorithms,while scripting languages are well suited for gluingapplications where the complexity is in the connec-tions. Gluing tasks are becoming more and moreprevalent, so scripting will become an increasinglyimportant programming paradigm in the next century.

I hope this article will impact the computing com-munity in three ways. First, I hope programmers willconsider the differences between scripting and systemprogramming when starting new projects and choosethe most powerful tool for each task. Second, I hopedesigners of component frameworks will recognize theimportance of scripting and ensure that their frame-works include not only facilities for creating compo-nents but also facilities for gluing them together. Finally,

I hope the programming language research communitywill shift some of its attention to scripting languages andhelp develop even more powerful scripting languages.Raising the level of programming should be the singlemost important goal for language designers, as it hasthe greatest effect on programmer productivity. It is notclear that strong typing contributes to this goal. ❖

Acknowledgments

This article has benefited from many people’s com-ments, including Joel Bartlett, Bill Eldridge, JeffreyHaemer, Mark Harrison, Paul McJones, DavidPatterson, Stephen Uhler, Hank Walker, Chris Wright,the Computer referees, and dozens of others who par-ticipated in a heated net-news discussion of an earlydraft. Colin Stevens wrote the MFC version of the but-ton example and Stephen Uhler wrote the Java version.

References

1. J. Ousterhout, “Additional Information for ScriptingWhite Paper,” http://www.scriptics.com/people/john.ousterhout/scriptextra.html.

2. C. Jones, “Programming Languages Table, Release 8.2,”Mar. 1996, http://www.spr.com/library/0langtbl.htm.

3. B. Boehm, Software Engineering Economics, PrenticeHall, Englewood Cliffs, N.J., 1981.

4. L. Wall, T. Christiansen, and R. Schwartz, Programming Perl,2nd ed., O’Reilly & Associates, Sebastopol, Calif., 1996.

5. M. Lutz, Programming Python, O’Reilly & Associates,Sebastopol, Calif., 1996.

6. R. O’Hara and D. Gomberg, Modern ProgrammingUsing REXX,Prentice Hall, Englewood Cliffs, N.J., 1988.

7. J. Ousterhout, Tcl and the Tk Toolkit, Addison-Wesley,Reading, Mass., 1994.

8. S. Johnson, “Objecting To Objects,” Invited Talk, UsenixTechnical Conf., San Francisco, Jan. 1994.

John K. Ousterhout is the CEO of Scriptics Corp. Hewas previously a Distinguished Engineer at SunMicrosystems Inc., where the work for this articlewas carried out. His interests include scripting lan-guages, Internet programming, user interfaces, andoperating systems. He created the Tcl scripting lan-guage and the Tk toolkit. He received a BS in physicsfrom Yale University and a PhD in computer sciencefrom Carnegie Mellon University. Ousterhout is a fel-low of the Association for Computing Machinery andhas received many awards, including the ACM GraceMurray Hopper Award, the US National ScienceFoundation Presidential Young Investigator Award,and the University of California at BerkeleyDistinguished Teaching Award.

Contact Ousterhout at ouster@scriptics.com.

Raising the level ofprogramming should

be the single mostimportant goal for

language designers,as it has the

greatest effect onprogrammer

productivity. It is not clear that strong

typing contributes to this goal.

.