You can help to create the next generation of programming tools!
We are software developers — just like you are. Our aim is to make programming better. We are frustrated by the quality of current development tools, and we are actively working to improve them. We are interested in anything that will help programmers to be more effective. Our work spans research and practice: we design and evaluate new programming languages, new type systems, tools for controlling concurrency, automated testing, IDEs, program analysis tools, security, and much more.
Our work has had significant impact on both industry and academia. Our tools are used daily by companies like Google and Microsoft, and of course in the open-source community. Oracle is including syntax in the Java 8 language that is designed to support our tools. Our testing techniques have been commercialized by multiple companies.
Our work is done in the context of the Programming Languages and Software Engineering Lab at the University of Washington. We have many remote collaborators and have successfully participated in GSoC in the past.
Please join us. We will teach you everything you need to be productive. You will have fun working on cutting-edge tools, you will learn a lot, and you will have real-world impact on software development.
Here is a selection of projects where you can contribute. We are also open to other ideas for these particular projects, or to other projects that improve software development. We look forward to hearing from you!
It is difficult to debug webpages, whose behavior evolves from a complex interplay of HTML, CSS, and JavaScript. Current debuggers are ineffective at capturing or reproducing nondeterministic or concurrent behaviors. We have devised a tool suite, Timelapse, that observes a website and records everything about its execution. This enables the recording to be replayed repeatedly, including inside a debugger. In addition to the record/replay technology, we have created new debugger visualizations and tools that enable the recording to be searched and played forward and backward.
Rather than debug problems after they occur at run time, it is better for the compiler to guarantee that certain errors cannot happen. For example, the compiler prevents you from writing int i = "hello world";. Wouldn't it be nice if the compiler could give a guarantee that your program never dereferences null, or that it does not side-effect data structures that it should not, or that all your regular expression and format strings are syntactically valid?
We have built a tool that gives a compile-time guarantee that certain run-time errors never happen, for Java programs. It works via pluggable type-checking: the idea is to replace the underlying Java type system by one that gives more guarantees. The Checker Framework is used daily around the world, and dozens of pluggable type systems have been built upon it — each one gives a different guarantee, and a user can choose whichever is most appropriate.
Do you dislike writing tests? No problem! Our Randoop tool can automatically generate test suites for you. It is based on random execution of methods, but the randomness is directed by analysis of the program and of previous test executions. Randoop is the state of the art in test generation. However, we would like to extend it further and to make it easier to use.
Program specifications (sometimes also called contracts) describe intended behavior. They are the sort of thing you would write in an assert statement. They are most often used for procedures: preconditions are requirements on the input, and postconditions are guarantees about the output. Specifications form useful documentation, and they can be used for proofs of correctness, run-time checking, test generation, and many other tasks.
Most programs don't come with a specification, so we have developed a tool, Daikon, that automatically generates one. Daikon runs a program, observes the values that it computes, performs machine learning over those values, and outputs a likely specification. Daikon works for programs written in C, C++, C#, Eiffel, F#, Java, Perl, and Visual Basic.
If you have any questions, please direct them to the appropriate developer mailing list, or send general questions to mernst@cs.washington.edu. We look forward to hearing from you!
A tip for applicants: We want your application to be successful. In order to do so, please don't just paste text directly from our project descriptions into your application form. Instead, show us how you are different from the masses of other applicants. Show that you have thought about the problem, have tried the tools, and/or have special skills or perspective. And tell us why this particular project is especially exciting to you. Applicants who do this have been most successful in the past. Thanks!