Doug Orleans
131 2nd St.
Cambridge, MA 02141
Advisor: Prof. Karl Lieberherr
Exploratory programming is an important part of the software engineering cycle: when a domain is not very well understood or open-ended, or it's not clear what algorithms and data structures might be needed for an implementation, it's useful to be able to interactively develop and debug a program without having to go through the usual constraints of the edit-compile-run-debug cycle. Many languages provide support for exploratory programming via interactivity, dynamicity, and extensibility, such as Lisp, Smalltalk, Self, Obliq, Cecil, Dylan, and Python. However, most exploratory programming languages (and language environments) only allow a single programmer to interact with the code and data being developed; if a team of programmers wishes to collaborate, they must use project management and revision control tools which greatly discourage or hinder an exploratory style. What I plan to study is how language-level support for multiple programmers can enable exploratory collaboration.
My interest in collaborative languages stems from my extensive experience with muds. What started as a multi-user text adventure game in 1979 has evolved into several varieties of multi-user programmable virtual worlds. The most popular (at least for non-game uses) is MOO; it has been used for such widely varied purposes as system administration[Eva93], software process modeling[DHW98], collaborative OO design[HS95], collaborative astrophysics research [VBBCN96], telepresence microscopy[ZSE+96], and distance learning[KLS+98]. In fact MOO can be used to implement almost any multi-user application, from web servers to conferencing systems, and while the virtual world aspect of MOO is useful for a number of these applications, I believe that the reason for its success is its programming language, which enables and encourages an exploratory method of collaborative programming.
From a programming language perspective, however, the MOO language has some serious deficiencies. While the system is technically object-oriented, having objects that inherit fields and methods from other objects, the high overhead of object creation and the lack of automatic object garbage collection means that in practice most MOO programs are not truly object-oriented; most data structures are implemented using the built-in list type, while objects are used solely for virtual-world entities (or prototypical parent objects of these entities). The lack of first-class functions further limits the expressiveness of the language. From my experience with mud development, I believe that multiple inheritance and predicate dispatch (a generalization of multiple dispatch)[EKC98] would greatly enhance the ability for incremental development and code re-use in a collaborative language as well. MOO has fairly comprehensive facilities for the introspection and invocation aspects of a meta-object protocol[KP96], but very little support for intercession, i.e. allowing certain objects to override default behavior of the object system, such as method dispatch or field update; I believe this is another feature that is very important for exploratory programming. Of course, the Demeter group here at Northeastern has studied a number of approaches to encouraging evolution and re-use at the level of collections of cooperating objects (e.g. adaptive plug-and-play components[ML98]), and it would be fruitful to investigate these ideas in the context of a collaborative language.
From a multi-user system perspective, MOO has some limitations as well. Chief among these is the fact that it only supports cooperative multitasking; if a task uses more than a certain amount of time, or performs more than a certain number of operations, without yielding, then it is terminated with no recourse for cleanup. True preemptive multitasking would be much more powerful. Another problem with MOO as a multi-user system is the Unix-style security system; each field and method has an owner and a set of flags for read and write permission. A capability-based security system such as that discussed in[Ree96] would be much more flexible and clean. Other areas of investigation include distribution and a more robust approach to persistence-- MOO runs as a monolithic process which periodically pauses to fork and dump a snapshot of its heap.
There have been a number of attempts to develop a collaborative programming language, both within and without the context of a virtual world system, with varying degrees of success. ColdC[Gil98] adds multiple inheritance, stronger encapsulation, lightweight objects, and a simple module system, as well as a more database-oriented persistent storage system. SchMUSE[BCLZ93] was a class-based distributed delegation object system built on top of MIT Scheme. Repo, used in the COTERIE toolkit[MF96] adds replicated objects to Obliq to support distributed interactive environments. CL-HTTP[Mal94] is a hypermedia server allowing users to write CGI scripts in Common Lisp. Matrix[Sar98] and POO[Str98] are projects attempting to add multi-user capabilities to Java and Python, respectively. Neverworld[Hor98] is a multi-user VRML world built on top of (and allowing users programmatic access to) Scheme48. Other collaborative language systems include MUQ, MudOS, COOLmud, FMPL, and Mu; these and other links (including all the references in this paper) can be found on my resources web page, http://www.ccs.neu.edu/home/dougo/mud/ .
For my Ph.D. thesis research I plan to investigate these systems in greater detail, with a focus on studying how language-level issues support collaborative exploratory programming. This may lead to the design and development of a new language, perhaps extending an existing collaborative language or else adding multi-user support to an existing exploratory language. I then intend to perform some experiments with users (perhaps based on the experiments in [Spr96]) to determine just how well this type of system enables exploratory collaborative programming, and how it compares both to single-user exploratory programming and collaboration with traditional tools. I also plan to investigate some of the theoretical issues of how best to formally model a collaborative language.
I have taken 6 classes since completing the Masters degree requirements:
My minor area of study is artificial intelligence, having taken three AI classes at NU. Of particular note is a paper I wrote for the Spring '98 quarter COM3411 class[Orl98]; this was an attempt to develop a natural language system for muds that did both parsing and generation using a unification grammar. Much of the work I did on JHCore (an object library for MOO) was related to natural language generation from template messages set by the user.
For the past two years I have been working as a part of the Demeter team on the implementation of the Demeter/Java system[HLM+98]. Prof. Lieberherr and I published a short description paper in the proceedings of ICSE 1997[LO97].
This document was generated using the LaTeX2HTML translator Version 97.1 (release) (July 13th, 1997)
Copyright © 1993, 1994, 1995, 1996, 1997, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
The command line arguments were:
latex2html -split 0 -dir html -no_navigation plan.
The translation was initiated by Doug Orleans on 10/16/1998