Softpanorama (slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-) Softpanorama Search

Recommended Scripting Papers

1. Why GAWK for AI? - draft of article by Ronald P. Loui.
2. Source code as human language -- interview with Tim O'Really
3. The Secret Life of Game Scripting
4. In Praise of Scripting:  Real Programming Pragmatism by Ronald P. Loui  
5. Java Makes Scripting Languages Irrelevant by Diomidis Spinellis

[Loui1996] Why GAWK for AI? - draft of article by Ronald P. Loui. (1996)

Most people are surprised when I tell them what language we use in our undergraduate AI programming class.  That's understandable.  We use GAWK.  GAWK, Gnu's version of Aho, Weinberger, and Kernighan's old pattern scanning language isn't even viewed as a programming language by most people.  Like PERL and TCL, most prefer to view it as a "scripting language."  It has no objects; it is not functional; it does no built-in logic programming.  Their surprise turns to puzzlement when I confide that (a) while the students are allowed to use any language they want; (b) with a single exception, the best work consistently results from those working in GAWK.  (footnote:  The exception was a PASCAL programmer who is now an NSF graduate fellow getting a Ph.D. in mathematics at Harvard.) Programmers in C, C++, and LISP haven't even been close (we have not seen work in PROLOG or JAVA).

Why GAWK?

There are some quick answers that have to do with the pragmatics of undergraduate programming.  Then there are more instructive answers that might be valuable to those who debate programming paradigms or to those who study the history of AI languages.  And there are some deep philosophical answers that expose the nature of reasoning and symbolic AI.  I think the answers, especially the last ones, can be even more surprising than the observed effectiveness of GAWK for AI.

First it must be confessed that PERL programmers can cobble together AI projects well, too.  Most of GAWK's attractiveness is reproduced in PERL, and the success of PERL forebodes some of the success of GAWK. Both are powerful string-processing languages that allow the programmer to exploit many of the features of a UNIX environment.  Both provide powerful constructions for manipulating a wide variety of data in reasonably efficient ways.  Both are interpreted, which can reduce development time.  Both have short learning curves.  The GAWK manual can be consumed in a single lab session and the language can be mastered by the next morning by the average student.  GAWK's automatic initialization, implicit coercion, I/O support and lack of pointers forgive many of the mistakes that young programmers are likely to make. Those who have seen C but not mastered it are happy to see that GAWK retains some of the same sensibilities while adding what must be regarded as spoonsful of syntactic sugar.  Some will argue that PERL has superior functionality, but for quick AI applications, the additional functionality is rarely missed.  In fact, PERL's terse syntax is not friendly when regular expressions begin to proliferate and strings contain fragments of HTML, WWW addresses, or shell commands. PERL provides new ways of doing things, but not necessarily ways of doing new things.

In the end, despite minor difference, both PERL and GAWK minimize programmer time.  Neither really provides the programmer the setting in which to worry about minimizing run-time.

There are further simple answers.  Probably the best is the fact that increasingly, undergraduate AI programming is involving the Web.  Oren Etzioni (University of Washington, Seattle) has for a while been arguing that the "softbot" is replacing the mechanical engineers' robot as the most glamorous AI testbed.  If the artifact whose behavior needs to be controlled in an intelligent way is the software agent, then a language that is well-suited to controlling the software environment is the appropriate language.  That would imply a scripting language.  If the robot is KAREL, then the right language is "turn left; turn right." If the robot is Netscape, then the right language is something that can generate "netscape -remote 'openURL(http://cs.wustl.edu/~loui)'" with elan.

Of course, there are deeper answers.  Jon Bentley found two pearls in GAWK:  its regular expressions and its associative arrays.  GAWK asks the programmer to use the file system for data organization and the operating system for debugging tools and subroutine libraries.  There is no issue of user-interface.  This forces the programmer to return to the question of what the program does, not how it looks.  There is no time spent programming a binsort when the data can be shipped to /bin/sort in no time.  (footnote:  I am reminded of my IBM colleague Ben Grosof's advice for Palo Alto:  Don't worry about whether it's highway 101 or 280. Don't worry if you have to head south for an entrance to go north.  Just get on the highway as quickly as possible.)

There are some similarities between GAWK and LISP that are illuminating. Both provided a powerful uniform data structure (the associative array implemented as a hash table for GAWK and the S-expression, or list of lists, for LISP).  Both were well-supported in their environments (GAWK being a child of UNIX, and LISP being the heart of lisp machines).  Both have trivial syntax and find their power in the programmer's willingness to use the simple blocks to build a complex approach.

Deeper still, is the nature of AI programming.  AI is about functionality and exploratory programming.  It is about bottom-up design and the building of ambitions as greater behaviors can be demonstrated. Woe be to the top-down AI programmer who finds that the bottom-level refinements, "this subroutine parses the sentence," cannot actually be implemented.  Woe be to the programmer who perfects the data structures for that heapsort when the whole approach to the high-level problem needs to be rethought, and the code is sent to the junkheap the next day.

AI programming requires high-level thinking.  There have always been a few gifted programmers who can write high-level programs in assembly language. Most however need the ambient abstraction to have a higher floor. 

Now for the surprising philosophical answers.  First, AI has discovered that brute-force combinatorics, as an approach to generating intelligent behavior, does not often provide the solution.  Chess, neural nets, and genetic programming show the limits of brute computation.  The alternative is clever program organization.  (footnote: One might add that the former are the AI approaches that work, but that is easily dismissed:  those are the AI approaches that work in general, precisely because cleverness is problem-specific.)  So AI programmers always want to maximize the content of their program, not optimize the efficiency of an approach.  They want minds, not insects.  Instead of enumerating large search spaces, they define ways of reducing search, ways of bringing different knowledge to the task.  A language that maximizes what the programmer can attempt rather than one that provides tremendous control over how to attempt it, will be the AI choice in the end.

Second, inference is merely the expansion of notation.  No matter whether the logic that underlies an AI program is fuzzy, probabilistic, deontic, defeasible, or deductive, the logic merely defines how strings can be transformed into other strings.  A language that provides the best support for string processing in the end provides the best support for logic, for the exploration of various logics, and for most forms of symbolic processing that AI might choose to call "reasoning" instead of "logic."  The implication is that PROLOG, which saves the AI programmer from having to write a unifier, saves perhaps two dozen lines of GAWK code at the expense of strongly biasing the logic and representational expressiveness of any approach.

I view these last two points as news not only to the programming language community, but also to much of the AI community that has not reflected on the past decade's lessons.

In the puny language, GAWK, which Aho, Weinberger, and Kernighan thought not much more important than grep or sed, I find lessons in AI's trends, AI's history, and the foundations of AI.  What I have found not only surprising but also hopeful, is that when I have approached the AI people who still enjoy programming, some of them are not the least bit surprised.

R. Loui (loui@ai.wustl.edu) is Associate Professor of Computer Science, at Washington University in St. Louis.  He has published in AI Journal, Computational Intelligence, ACM SIGART, AI Magazine, AI and Law, the ACM Computing Surveys Symposium on AI, Cognitive Science, Minds and Machines, Journal of Philosophy, and is on this year's program committees for AAAI (National AI conference) and KR (Knowledge Representation and Reasoning).  

Source code as human language -- interview with Tim O'Really

Source code as human language -- interview with Tim O'Really

...O'Reilly sees the excitement of the future attaching to "infoware." While waves of consultants periodically proclaim that content is king, O'Reilly has in mind a category more dynamic and active than online movies or digitized paintings. For him, as he explains in a piece called "The Open-Source Revolution," "infoware embeds small amounts of software in a lot of information." Those little, but well-integrated, pieces of intelligence make Amazon and comparable "information applications" the winners they are.

..That architectural vision of small, well-integrated pieces of software is the central theme of scripting, of course. O'Reilly is right to characterize current infoware as "HTML plus scripting." 

...He understands the rules well enough to be consistently profitable, but the most distinctive aspect of O'Reilly's vision of software is to see it as expression more than product. His delight is evident when he describes the progress the Electronic Freedom Foundation is making in its legislative goals by presenting software as speech rather than invention. He consistently talks about applications in the language of the theater or gallery.

... scripting is often dismissed as "quick and dirty stuff that is somehow less significant than the programming behind compiled commercial applications." Rather than fighting this aspersion, he inverts it, and explains that scripting is simply "closer to what people need ... Most speech is extemporaneous, not prepared. Conversation would be pretty stilted if everything one said was prepared, formal speech." Scripting is an extension of speech that powerfully matches the way people really learn and accomplish what they want when relating to computers.

...Duct tape is perfect for stuff at the edge." Crews specializing in performance or experiment setup know how to use throw away components to get a concert hall or laboratory in shape for special events. Scripting's flexibility also fits the temper of current management literature, which emphasizes quick response and not-necessarily-perfect solutions.

... Scripting in general, he said, "will find itself more and more interwoven" with the infoware that has begun to define how people relate to computers. Their high-level expressivity, openness to other technologies, and "failsoftness" will keep scripting languages on a steep growth curve.

One of the motivations for O'Reilly's Unix Power Tools, for instance, is the "natural progression" in Unix from the command line to simple scripts to more powerful languages. Perl creator Larry Wall describes the linguistic thinking underlying Perl as a progression that mimics the way people learn and use natural languages.

As Wall puts it, languages that follow this natural "speech" progression are fundamentally more accessible -- more democratic -- than "languages that don't let you speak at all until you have the equivalent of a college education."

..."Once you start thinking of computer source code as a human language, you see open source as a variety of 'free speech.' Free speech is not just a political ideal. It is the currency of science and of western civilization. It is a truism in the Western academic tradition dating back to the Renaissance that exposure to criticism and dialogue are the surest ways to refine ideas," O'Reilly said.

While such familiar open source products as "Linux, Apache, Sendmail, and BIND have had an enormous effect on the computer industry," O'Reilly argues that "scripting languages make the open source ethic even more universal. Because scripting languages are interpreted, their 'source code' is almost by definition open. This makes the community of discourse enabled by 'HTML-plus-scripting'... orders of magnitude greater than the community of hard-core developers working in higher-level languages."

[Loui2005] In Praise of Scripting:  Real Programming Pragmatism by Ronald P. Loui  

The real shock is that the academic programming language community continues to reject the sea change in programming practices brought about by scripting.  Enamored of the object-oriented paradigm, especially in the undergraduate curriculum, unwilling to accept the LAMP (Linux-Apache-MySQL-Perl/Python/Php) tool set, and firmly believing that more programming theory leads to better programming practice, the academics seem blind to the facts on the ground.  The ACM flagship, COMMUNICATIONS OF THE ACM for example, has never published a paper recognizing the scripting philosophy, and the references throughout the ACM Digital Library to scripting are not encouraging.

... ... ...

Part of the problem is that scripting has risen in the shadow of object-oriented programming and highly publicized corporate battles between Sun, Netscape, and Microsoft with their competing software practices.  Scripting has been appearing language by language, including object-oriented scripting languages now.  Another part of the problem is that scripting is only now mature enough to stand up against its legitimate detractors.  Today, there are answers to many of the persistent questions about scripting:  is there a scripting language appropriate for the teaching of CS1 (the first programming course for majors in the undergraduate computing curriculum)?  Is there a scripting
language for enterprise or real-time applications?  Is there a way for scripting practices to scale to larger software engineering projects?

[Spinellis2005] Java Makes Scripting Languages Irrelevant by Diomidis Spinellis. This can be considered as classic Java apologetics. Problems with high cost of development, slow debugging, java class libraries hell, etc are swiped under the carpet.  That author claim that "The gap between system programming languages and scripting languages is slowly closing.  For example, some scripting languages are capitalizing on Java’s infrastructure by having their code compile into JVM bytecode.   However, there is still a lot of ground in the middle that is up for the grabs.  New system programming language designs can offer more of the advantages now available only through scripting, while scripting languages are constantly benefiting from hardware performance advances that make their (real or perceived) efficiency drawbacks less relevant every day.  The issue of the result’s quality remains an open question on both fronts."

Rumors of the death of scripting languages ...

Notice, how most of  the nice features applications obtain through the use of scripting languages are now offered by Java:

• automatic memory management through garbage collection,
• a standard string data type,
• collection interfaces implementing most useful data structures, and

• a very rich language library.

In addition, in applications written in Java what can be considered as an API already comes for free as part of their object-oriented design.  One only needs to allow an application to dynamically load user-specified classes, expose its API by providing access to some of the application’s objects, limit the application’s exposure through the security manager and exception handlers, and the need for a separate scripting language vanishes. 

In fact, many modern Java applications that support beans, plugins, and other extension mechanisms, follow exactly this strategy.  Eclipse, Maven, Ant, Javadoc, ArgoUML, and Tomcat are some notable examples.  Even on resource-constrained embedded devices, such as mobile phones, which are still programmed in a system programming language, configuration and customization is currently moving toward the Java direction.

... are greatly exaggerated

Does the trend of customizing applications through a Java interface make scripting languages irrelevant?  Yes and no.  As an application configuration and extension mechanism, Java is probably the way to go.  The cost of marshalling and unmarshaling data objects and types between the application's code written in Java and the conventions expected by a different scripting language is too high for the limited incremental benefits that the scripting language would offer.  On the other hand, scripting languages still have an edge in a number of areas, offering us a number of distinct advantages.

A more flexible or imaginative syntax. Think of Perl's numerous quoting mechanisms and its regular expression extension syntax, or Python's use of indentation for grouping statements.  These make some program elements a lot easier to read.  As an example, variable substitution within Perl’s or the Unix shell’s double quoted strings is by far the most readable way to represent a program’s output.

Less fuss about types. Most scripting languages are typeless and therefore easier to write programs in.  For example, Perl makes writing a client or server for an XML-based web service a breeze, whereas in Java we have to go through a number of contortions to implement the same functionality.  Of course, the robustness and maintainability of code written in a typeless language is a different question, as many of us who maintain production code written in a scripting language later discover.

A more aggressive use of reflection. Consider here Perl's eval construct and Python's object emulation features.  These allow the programmer to construct and execute code on the fly, or dynamically change a class’s fields.  In many cases these features simplify the construction of flexible and adaptable software systems.

Tighter integration with command-line tools. Although Java 1.5 comes with an API containing over 3000 classes—with thousands more being available through both open source and proprietary packages—many operations can still be performed in a more reliable and efficient manner by interfacing with venerable command-line tools.  The Unix scripting languages provide many facilities for combining these tools, such as the creation of pipelines, and the processing of data through sophisticated control constructs.

Viability as a command language. Many scripting languages, such as the ones of the operating system shells, can also double as a command language.  Command-line interfaces often offer a considerably more expressive working medium than GUI environments (we’ll expand on that in another column).  Coupling a command-line interface with a scripting language means that commonly executed command sequences can easily be promoted into automated scripts; a boon to developers.  This coupling also encourages an exploratory programming style, which many of us find very productive.  I often code complex pipelines step by step, examining the output of each step, before tacking another processing element at the pipeline’s end.

A shorter build cycle. Although for many systems a build cycle that provided time for an elaborate lunch is now sadly history, the tight feedback loop offered by the lack of a compilation step in scripting languages allows for rapid prototyping and exploratory changes, often hand-in-hand with the end-user.  This is a feature that those using agile development methodologies can surely appreciate.

So, where do we stand now?  The gap between system programming languages and scripting languages is slowly closing.  For example, some scripting languages are capitalizing on Java’s infrastructure by having their code compile into JVM bytecode.   However, there is still a lot of ground in the middle that is up for the grabs.  New system programming language designs can offer more of the advantages now available only through scripting, while scripting languages are constantly benefiting from hardware performance advances that make their (real or perceived) efficiency drawbacks less relevant every day.  The issue of the result’s quality remains an open question on both fronts.

We developers, as avid tool users, enjoy viewing the battle from atop, reaping the benefits.

Diomidis Spinellis is an associate professor in the Department of Management Science and Technology at the Athens University of Economics and Business and the author of Code Reading: The Open Source Perspective (Addison-Wesley, 2003).  Contact him at dds@aueb.gr.

Comparing Python to Other Languages

Comparing Python to Other Languages by Guido van Rossum

An evaluation of various free programming languages  by  Keith Waclena . I

A Language Collector Comments On: Java, Perl & Python, by David Rook, in the Oct, '97 issue of a Navy computing publication, Chips.

Comparisons of Tcl with other systems

extensive discussion by  Wayne Christopher focused around Tcl.

Python/Tcl comparison (postscript) produced in the course of evaluation of interpreted languages for use in Alice (originally from U. VA.), a virtual-reality modelling engine which uses Python.

Sjoerd Mullender created a comparison of Python and TCL.

Frank Stajano's paper, Implementing the SMS server, or why I switched from Tcl to Python, was presented at the Seventh Internation Python Conference. (Also available in PDF.) -- read, but do not believe the author  :-)

What's wrong with Perl

One of the first things I discovered I didn't like was the syntax. It's very complex and there are lots of operators and special syntaxes. This means that you get short, but complex code with many syntax errors that take some time to sort out.

It also means that reading someone elses code is difficult. You can't easily understand someone elses scripts and adapt them to your own needs, nor can you easily take over the maintenance of someone elses program.

Some have argued that Perl is more like natural languages than most programming languages, and this certainly seems correct to me. And to me that is a disadvantage: natural language is extremely complex, ambiguous and full of subtle nuances and meanings. I certainly don't want my programs to be like that, but it seems that some do. I guess the reader will have to find out for him/herself which category s/he belongs in.

Many of Perls features are built right into the language core itself, instead of being placed in separate libraries. One example of this is the handling of regular expressions, for which there is a special syntax. This has the advantage that there are some convenient ways of doing the things that are done most often, but it also means that you don't get the advantages of objects.

In other words, you can't precompile a bunch of regular expressions and stick them in a list. You can't return a precompiled regular expression from a function or set a variable to a regular expression. (I've been told that this has changed in Perl 5.005, but have not seen any example code. I would be grateful if anyone could provide this.)

Another major disadvantage to Perl is that of function (or subroutine, in Perl lingo) signatures, or rather, the lack of signatures. In most programming languages when you declare a function you also declare its signature, listing the names of the parameters and in some languages also their types. Perl doesn't do this.

Although object-orientation is not as fantastic as many would like us to think, Perl actually does support it. However, it does so only half-heartedly, since objects were added rather late in the life of the language.

The result of this is that files, sockets, hashes and lists are not objects, and that you cannot create objects that behave like these built-in types, which is a real pity and rather awkward at times.

 A Language Collector Comments On Java Perl & Python

Python. From the outside Python looks like C++ and has many OOP (object oriented programming) features, but without much of the complexity of C++.

For instance, Python is a self-typed language. Assign a string to a variable and the variable is assigned storage as a string. If you later use the variable in an arithmetic expression, you get a compile error. You also get a compile-time error if you try to do arithmetic with uninitialized variables. The reason is that uninitialized variables don't have a type, and some data types can't participate in arithmetic expressions.

Once you stop using a variable, it gets reclaimed (garbage collected) automatically. This is important because C++ programmers tend to devote a large portion of code (10 to 20 percent) to preparation for and execution of the memory allocation/reclamation process. While C++ makes the setup/tear down process easier than with C, Python makes it unnecessary.

Grab-bag of Python features:

• Though the syntax is a little different, Python has classes and inheritance very much like C++. This gives it both power and brevity of expression.
• The special syntax for list (array) operations is both simple and powerful.
• Integers are like C long ints.
• Unlike most languages, Python's long integers have unlimited size. Want to count the national debt in pennies? No problem in Python. Floating point in Python is handled like a C double.
• Dictionaries are associative arrays that allow objects to be stored and fetched by key.
• Python has exception handling much like the latest C++.

While none of these features are really earth-shaking, the concise, consistent architecture is a welcome relief.

Another feature is that Python is both compiled and interpreted. When you run a Python program it's automatically com piled to pycode (aka pseudocode, like Java's bytecode) and then interpreted. Pycode generally runs about 100 times slower than native code, but now we get to another interesting feature. It's relatively easy to mix and match Pycode and regular C or C++. The typical scenario is to develop in Python then convert modules that don't run as fast as you want to C or C++. C can be called from Python and vice versa!

The ability to support RAD (Rapid Application Development) with Python is the key to its success. The most concise description of Python I can think of is, "Python is executable pseudo-code". This is exactly what I wanted for my human-friendly firewall logs.

It's impossible for me to detail all the neat things I've found in Python in a page or so. If you're interested in programming (and you must be or you wouldn't still be reading this...) check it out for yourself at http://www.python.org. You can find WIN95, WINNT, Unix and other flavors of Python interpreters there.

The 881 page Programming Python by Mark Lutz (O'Reilly & Associates Inc.) provides a good tutorial on Python, but to get the true flavor of the language you need to see some real-world source code. Fortunately, the Python source code (in a combination of Python and C) is available free on the Internet.

The What Why Who and Where of Python

Do-it-yourself benchmarking - SunWorld - January 1999

Line counts in C or Java are about three times more than those in Tcl for the same activity. This difference is crucial: experimentation in these languages seems like a chore, while the comparable work in Tcl is entertainingly easy.

Do-it-yourself benchmarking - SunWorld - January 1999 -- A look at scripting performance and project feasibility.

Tom Christiancen compared Perl and Python

... Python does not resemble C very much, nor in fact does it resemble awk, sh, sed, or any other Unix utility really at all (whereas Perl does). It doesn't have assignment operators or autoincrement operators or anything like that, all of which seem to deeply confuse non-C programmers. Both have an interactive mode for easy debugging. Python was designed ab initio to be object-oriented and have clear module semantics (although I think some folks find the namespace games messy). It is nearly as fast as Perl, but doesn't have so powerful regular expression stuff as Perl, nor does it have function pointers with deep binding (read: closures), and a variety of other things I forget right now. The Unix interactions Perl is so good at can probably be taken care of in Python using the proper extension module (beware though, as that's what they'll say about extended tcl in incrtcl as well, and down that path lies madness). I'm pretty sure there's no way to take a pointer to something: it's all implicit, for both good and bad. I'm not sure what if anything at this point Python has that Perl doesn't.

One of those most annoying things about Python for many people is that it intuits block structure from indentation alone.

Its loops look like this

    while 1:
	    buf =index.html fp.read(blocksize)
	    if not buf: break
	    conn.send(buf)

In Perl, that would be

    while (1) {
	$buf = $fp->read($blocksize);
	if (not $buf) { last } 
	$conn->send($buf);
    } 

... ... ... 

Don't screw up on indentation though, or you'll screw up on blocks! Perl at least fixes C's ambiguity by REQUIRING curleys for blocks. This seems to help a LOT of people.

Python also tolerates newline as a statement separator. That means that you're going to have to do some surprising things at times. For example this:

    a = 3 * 5
	- 12;

won't work.

In summary, there's a great deal of overlap in functionality between the two. The extent to which you prefer one over the other will probably depend on how comfortable you already are with C and Unix shell programming in general. It may also depend on whether they're already a library written (or a primitive) to do what you want, like database manipulation, math stuff, forms entry, graphics (windows or pixels) extensions. Perl is also a bit older and far more widespread than Python, and Perl ships with a number of vendor systems. 

 

New choices for scripting - SunWorld - February 1999

...Even after years of confronting it, the popular belief that scripting is "unsafe" or "only for toy problems" continues to surprise us. Part of the difficulty is that many of the specific details for which critics fault such languages are in fact strengths or, at worst, non-issues. (Example: Yes, there are far fewer software engineering utilities sold for Perl than for C. Any dispassionate observer, though, would agree it's a good thing that Perl semantics don't permit memory violations, and thus don't deserve all the checking that is a practical necessity when coding in C.)

...Beside algorithmic expressiveness, one of the best things about scripting is that it encourages practitioners to exploit code-data dualities. This is crucial in such examples as Tk's remarkable success as a cross-platform, cross-language graphical toolkit. The same principle of communication through exchange of simple, human-readable encodings, has powered scripting's dominance in network domains like CGI and exploitation of new protocols.

...The problem seems to be this: High-level coding is so easy and even fun that programmers quickly become expert at it. They become expert at clever and supple construction of subtle algorithms. Designing robust architectures, though, is very different, and many of the same programmers never learn the necessary skills. Their instinct is to just keep programming until a problem gives up from exhaustion.

...Scripting, especially string-oriented languages such as Tcl, have the potential to merge stored and loaded data "formats", and get rid of this whole mess. The missing link is the ability to reorganize live data. ...

• Douglas Bennett's Designing Hard Software http://www.manning.com/Bennett/index.html
• Conferences hosting Python Tutorials http://www.python.org/psa/teachers.html
• Eighth International World Wide Web Conference http://www8.org/
• Developers' Day at Eighth International World Wide Web Conference http://www8.org/developers.html
• Full listing of past Regular Expressions columns http://www.sunworld.com/sunworldonline/common/swol-backissues-columns.html#regex

XOTCL - an Object-Oriented Scripting Language Accepted for publication in:
Proceedings of 7th Usenix Tcl/Tk Conference (Tcl2k), Austin, Texas, Feb 14-18, 2000

This paper describes the object-oriented scripting language XOTCL (Extended OTCL), which is a value added replacement of OTCL. OTCL implements dynamic and introspective language support for object-orientation on top of TCL. XOTCL includes the functionality of OTCL but focuses on the construction, management, and adaptation of complex systems. In order to combine the benefits of scripting languages with advanced object-oriented techniques, we extended OTCL in various ways: We developed the filter as a powerful adapation technique and an intuitive means for the instantiation of large program structures. In order to enable objects to access several addition-classes we improved the flexibility of mixin methods by enhancing the object model with per-object mixins. We integrated the object system with the TCL namespace concept to provide nested classes and dynamic object aggregations. Moreover, we introduced assertions and meta-data to improve reliability and self-documentation.

The safety of scripting - SunWorld - October 1998

When language theoreticians and proponents write about "safety," their first thought is usually about the kind of semantic questions Java's exception-handling addresses. Suppose you're coding an application, and you mistakenly ask for the thirteenth element of an array or vector with 10 members...... ... ...

Less coding yields fewer errors in coding. The incidence of errors in programming seems remarkably constant, at a few per hundred lines of finished source...

...the expressiveness of scripting encourages source studies. Peer review is one of the surest paths to quality in implementation, and so anything that encourages colleagues to read source code is likely to yield large returns. Scripting languages are designed to be easy to use. The consequence is that they're also relatively easy to read...

Scripting's encouragement of "glueing" gives an under-appreciated safety benefit...

...While C mostly reuses individual functions, scripting languages emphasize encapsulation of whole processes at a time. Most scripting languages present a variety of "glues": hooks to connect processes, CORBA or DCOM components, client/server pieces, and so on, all the way down to individual C functions. This makes it a straightforward matter to "move the boundaries" of an architecture, even after a prototype has been accepted. Stewart Brand's How Buildings Learn: What Happens After They're Built is a marvelous essay ("the best book I've ever done," Brand says) in which he argues that the best buildings are those that match their occupants' lives. It's good to be able to tear down walls, reroute plumbing, or build other walls. Scripting is in the spirit of Brand's human-scale building. Scripted solutions adapt through their life cycle with relatively little trauma.

... Java is good for building monuments -- architectures destined to endure without change. Scripting languages tend to yield something more like "temporary school buildings" put up in emergencies which are still in use a half-century later.

So, which philosophy is a safer choice for your next project? With scripting languages, the nice thing is that you don't have to choose. You can use scripting's glueing capability to rely on as much or as little of a scripting language as is best for your situation. Scripting languages cooperate well with a formal approach (several have interfaces to Ada), and yet remain easy to use for beginners. Pick the mix of characteristics you need, and you're likely to find a scripting language that fits the bill