Software developers aim to create reliable software at low cost. Two types of tools that help in this task are static and dynamic analysis tools. Static analysis tools reason about the program source code, without ever running the program; a widely-used example is type systems. Dynamic analysis tools observe the program as it executes; a widely-used example is testing. Dynamic and static feedback provide complementary benefits, neither one dominates the other, and at any moment only the programmer knows which one would be most useful. Unfortunately, current programming languages impose too rigid a model of the development process: they favor either static or dynamic tools, which prevents the programmer from freely using the other variety. We propose a new approach, in which the developer always has access to immediate execution feedback, and always has access to sound static feedback. The key broader impact is to permit developers to work the way they find most natural and effective, which will improve reliability and reduce cost. Developers will create software that is more reliable than that created in an environment that favors dynamic analysis. Developers will work faster than they can in an environment that favors static analysis.
It is well-known that dynamically-typed scripting languages and statically-typed programming languages have complementary strengths. For example, scripting can permit faster and more flexible program development and modification, whereas programming languages can yield more reliable and maintainable applications. Our goal is to give programmers the benefits of both scripting languages and programming languages, so that a programmer can shift back and forth between the two paradigms depending on the task at hand. In our approach, a programmer can view and execute a program through the lens of sound static typing, or can view and execute a program through the lens of dynamic typing with no statically-imposed restrictions. Furthermore, the programmer can switch between these two views as often as desired, or can use them both simultaneously, depending on the programmer's current information needs. In our approach, a programmer may temporarily disable the type system and test the code, even if the code does not type-check. The code is executed as if no types had been written. Type errors (inconsistencies between the execution and the declared types) are logged but do not terminate execution. The logged errors can be examined if the test fails or deferred if the test succeeds. This mode is appropriate for tasks such as initial prototyping, evolving an interface, representation changes, library replacement, and exploratory refactoring.
