Scripting languages are lightweight, dynamic programming languages designed to maximize productivity by offering high-level abstractions and reducing the syntactic overhead found in most system's languages. The rising popularity of scripting languages such as Perl, Python, PHP, Tcl, JavaScript, Ruby, and Groovy have many underlying causes: they allow partial execution of programs, permitting easy unit testing, interactive experimentation, and even demoing of software at all times; their support for powerful and flexible high-level datatypes and dynamic typing admits quick interim solutions that can later be revised; etc.  In short, scripting languages optimize developement time rather than machine time, a good approach early in the software development life cycle.

However, once the understanding of the system has reached a critical point and requirements have stabilized, scripting languages become less appealing. The compromises made to optimize development time make it harder to reason about program correctness, harder to do semantic-preserving refactorings, and harder to optimize execution speed. The lack of type information makes the code harder to navigate.

This situation often leads to a rewrite of a program in a less dynamic language, which may be costly and may introduce many bugs due to human error or semantic differences between the scripting language and the new target language (e.g., lack of garbage collection in C++, stricter type rules in Java, differences in available libraries, etc.). Sometimes only parts of the program are reimplemented, e.g., in C or assembler, as an optimization technique for a particularly computation-intensive method.  Bridging a high-level scripting language to lower-level C introduces new opportunities for errors, possibly introduces platform-specific ties, and increases the number of languages a programmer must know to maintain the system. Both these approaches, especially the first one, have the downside of slowing down future development as they effectively preclude further use of the scripting language for prototyping new features.

Recently, the concept of pluggable types has been proposed, which encourages the use of different optional type systems which do not have any effect on the run-time semantics of the programming language. It is believed that untyped scripts can be retrofitted to work with pluggable type systems (2), but with very few exceptions (i.e., Strongtalk), practical reports are yet to be found. Various ways of integrating or interfacing typed with untyped code have been proposed, like gradual typing, which allows for evolving script code to a more ``safe state'' more suitable for program analysis and compile-time optimisations.

The STOP workshop is interested in evolution of scripts in the sense of largely untyped pieces of code into safer programs, with more rigid structure and constrained behaviour through the use of gradual/hybrid/pluggable typing, optional contract checking, extensible languages, refactoring tools, and the like. The goal is to further the understanding of such systems in practise, and connect practise and theory.

The subject areas that this workshop proposes to address have recently seen increased interest by several research groups, but there is no common understanding of how gradual/hybrid/pluggable typing, script to program evolution, typed to untyped evolution, etc. interplay, and there are few experience reports from extant languages that support pluggable types or optional type annotations (Cecil, CLOS, Dylan, PLT Scheme, Strongtalk, and others). This workshop aims to bring researchers together for passionate discussion about these topics, and to promote not only the theory, but practical evalution of these ideas, and experience reports.