Programming is a difficult task. The goal of a programming environment is to provide tools that help the programmer and simplify the task. We are a strong proponent of programming tools and have been developing such tools for a long time. While an undergraduate, I worked on the Dartmouth Basic runtime system. One of the key innovations here was to add a source-language debugger to the environment.
Our real research in programming environments started with the advent of workstations (Apollos, Suns, Percs, ...). We (along with several other groups) felt that one should be able to make use of the additional computational power and the graphics display to simplify and enhance the programming experience. Our initial attempt here is reflected in the PECAN system. PECAN used compiler technology to generate a tool suite for a language. The tool suite included textual (partially syntax-directed) and graphical (Nassi-Schneiderman diagrams, Rothon diagrams) editors, semantics views of the symbol table, control flow, and expressions, and execution views of the stack and the code. It also featured incremental compilation as the user typed. It was a fun system and taught us a lot, but it really wasn't practical (it ran out of memory at about 1000 lines of code), and didn't take full advantage of the graphics capabilities of workstations.
Based on this work, we next tried to make better use of the graphical capabilities of workstations by using visual languages. We realized that visual languages usually only cover a limited part of programming (e.g. only control flow or only data flow), and that to do real programming we would have to let the programmer work with multiple such languages. To accomplish this we developed what we called a conceptual programming environment, GARDEN, that let the programmer develop new visual or textual languages (with appropriate visual syntax and appropriate semantics), and nest and otherwise intermix these languages in a full system. The system provided appropriate graphical and textual editors, a Lisp-like base language, a full shared object store (to let multiple programmers work on the same program at once and to support distributed applications), Smalltalk-like browsers, multiple threads, and even a compiler. The system was used to develop a wide variety of visual languages.
While developing GARDEN, several people challenged the overall research in programming environments, claiming that while the tools that we and others were developing were nice and might be useful, nothing was actually practical and none of the projects could really use themselves for development; everyday development of programs on UNIX (or any other OS at that time) was done using separate and textual editors, debuggers, etc. that hadn't changed significantly in ten years. We thus started developing a practical environment for real programming. We realized that you didn't need to have a common store or central representation to have an integrated environment, nor did you need to develop new tools to have graphical front ends. Instead we developed a simple message-based integration mechanism that let tools talk to one another, and a series of wrappers that provided graphical interfaces to existing tools (dbx, gdb, make, rcs, ...). The result was the FIELD environment. As it was developed, we extended the environment with a variety of graphical views including structural views (flow chart, class hierarchy), and dynamic views (data structure displays, heap vizualization, I/O visualizations). FIELD was quite successful. We used it for several years in our intro programming courses, it was commercialized by DEC (as FUSE), and was copied by HP (Softbench), Sun (Tooltalk), SGI, and others.
Our next environment, DESERT, tried to extend FIELD in several ways. First, it wanted to provide the programmer with a high-quality display of the code. This was done by extending Adobe Framemaker as a program editor. The extension featured Baeker-Marcus style code formatting that was done as the user typed which included semantic lookup of symbols over the whole system (and not just the current file). Second, we wanted to let the programmer view the system in different ways, being able to isolate the code relevant to a particular change or feature. This was done by splitting the program into fragments and having the editor work on virtual files consisting of different fragments gathered from actual source files. The programmer could specify a set of fragements using appropriate queries. Fragments were under configuration management and changes made to the virtual files were integrated into the original source files when the virtual files were saved. Finally, we wanted to provide higher quality visualizations of code and execution and thus developed a 3D visualization system that was integrated into the environment.
Our more recent efforts have concentrated on providing support for evolution and software consistency rather than attempting to provide a comprehensive programming environment. This package, CLIME, assumes there are tools for creating and maintaining all the different artifacts that accompany a software system: the specifications, design, source, test cases, documentation, etc. The semantics of each of these artifacts is then defined in terms of a set of metaconstraints with respect to the other artifacts. The design is viewed as contraints on the source (and vice versa) so that a class in a UML diagram has to have a corresponding class in the source; language usage rules constrain the form of the source; documentation must be consistent with the code; test cases must cover the code and be rerun as the code changes. All this is checked incrementally as the use edits the artifacts and any resulting inconsistencies are displayed using a graphical interface.
While CLIME concentrates on the static structure of the source and the various software artifacts, we realized that some of the specifications and design artifacts related to the behavior of the application rather than the code itself. To accommodate this, we have been developing CHET, a tool for checking class and library specifications in real software systems. CHET can take input based on a extended automata over events (which can be derived from UML interaction diagrams, class contracts, etc.), find all instances of the specification in a large system, and then check each instance.
Our most recent work involves a new front end for programming environments, Code Bubbles. This work goes gback to the Desert view of
showing fragments of files, such as individual functions, and is designed so that the programmer
can see all the relevant code for their current task, effectively their current working set, on the
screen at one time.
A translation of this page into Swedish is available thanks to Weronika Pawlak.
A translation of this page into Polish is available thanks to Marie Stefanova.
A translation of this page into Russian is available thanks to Deepak Khanna.
A translation of this page into Portuguese is available thanks to Artur Weber and Adelina Domingos.
A translation of this page into Ukranian is available thanks to Irma Alekseeva.
A translation of this page into French is available thanks to Random Password.
A translation of this page into Czech is available thanks to Alan Alaxandar.
A translation of this page into German is available thanks to Fa Teknoloji.
A translation of this page into Greek is available thanks to Vouchers Tree.
A translation of this page into Armenian is available thanks to Estonian is available thanks to Martin Aus. Polish is available thanks to Grzegorz Adamski. Chinese is available thanks to PlayerAuctions. Urdu is avaiable thanke to Mobile Mall.