Heading:

PE report (section 2)

Page Numbers: No

Introduction

How should we compare programming environments?

Before considering particular features that we feel contribute to "good" programming environments, it is important to consider how we can tell that one programming environment is "better" than another.

Any evaluation must be in some context. There is no reason to believe that some one programming environment could be optimal for all kinds of programming in all places at all times. In our discussions, we have focussed our attention on the foreseeable needs within CSL in the next few years, with particular attention to "experimental programming." We have taken experimental programming to mean the production of moderate-sized systems that are usable by moderate numbers of people in order to test ideas about such systems; Bravo and Laurel were seen as typical of such experiments, but we believe that it will be important to conduct future experiments more quickly and at lower cost.

It is difficult to quantitatively compare programming environments, even in fixed contexts. A large number of qualitative comparisons are possible, but the more convincing ones all seem to fall into two categories, both based on the premise that the purpose of a programming environment is, above all, to facilitate programming:

A good programming environment will reduce the cost of solving a problem by software. The cost will include the time of programmers and others in design, coding, testing, debugging, system integration, documentation, etc., as well as of any mechanical support (computer time, etc.). Since our human costs continue to be dominant, one of the most convincing arguments in favor of a particular programming environment feature is that it speeds up some time-consuming task or reduces the need for that task (e.g., it might either speed up debugging or reduce the amount of debugging needed). Bottleneck removal is the implicit argument in much that follows.

A good programming environment will also improve the quality of solutions to problems. Measures of quality include the time and space efficiency of the programs, as well as their usability, reliability, maintainability, and generality. Arguments relevant to this category tend to be of the form "this feature reduces the severity of a known source of problems," or "this feature makes it easier to improve an important aspect of programs." Thus a feature might be good because it reduces the frequency of crashes in programs or because it makes it convenient to optimize programs’ performance.

(These two categories could be reduced to one by noting that there is a tradeoff between cost and quality. Thus by fixing cost, we could compare only quality; by fixing quality, we could compare only cost. This seems to complicate, rather than simplify, a qualitative evaluation of features, so we will not seek to unify these two kinds of argument.)

In the discussion that follows, we have attempted to relate our catalog of "important features" to these more general concepts of what makes a "good environment" whenever the connection is not obvious. In some cases, we have not been entirely successful, because our experience "tells" us that something is essential, but we haven’t been able to analyze that experience to find out why. In all cases, our arguments are more intuitive than logically rigorous. Strengthening these arguments would be an interesting research topic.

We have been largely guided by experience with three current programming environments available to the PARC community: Interlisp, Mesa (with Bravo), and Smalltalk. Both what we know about the strengths and what we know about the limitations of these environments have been taken into consideration. It is of course dangerous to generalize too boldly from the intuitions and preferences of users: it is virtually impossible to be certain that the useful features have been clearly distinguished from those that are merely addictive.

Conclusions

We are somewhat surprised at how little disagreement remains in our rather mixed group. Our priority ranking of PE features (see section 4) is numerical evidence of this, and the minutes of our discussions (on [Ivy]<Deutsch>per>minutes>*) provide further, qualitative support for the same point. There are, of course, differences about the relative importance of many features, but hardly any about the five-level priority assigned to each feature, or about how hard things are to do. We therefore urge that discussion should focus on the value of an EPE to CSL, and how it is to be achieved, rather than on detailed argument about individual features.

As we said above, the purpose of a PE is to improve the productivity of programmers or the quality of programs. We don’t know how to quantify quality, but we did think about how much more productivity we might expect for sizable projects (e.g. Laurel, Bravo or the travel planner), as compared to the current state of affairs in either Lisp or Mesa. We guess that a factor of four is possible, about half from relaxing current space and time constraints by moving to the Dorado, and half from a PE which has our A, B, and C priority features, and a respectable sprinkling of the others.

How will all this productivity be applied? We anticipate three major effects.

First, many more interesting things will be within the scope of a single person’s efforts. Hence, the number of Laurel-sized projects can be expected to increase dramatically; not only are they much less work to do, but it is much easier to organize a one-person that a four-person project.

Second, much more elaborate things will be feasible, and hence will be attempted.

Third, the evolution of good packages which can be easily used without disastrous time, space or naming conflicts will cause a qualitative change in the nature of system-building: the current Interlisp system gives us our few hints of what this change will be like.

What next? We think that CSL can support only one major PE, and that it can be evolved from either Lisp or Mesa; Smalltalk is farther from our goals, though certainly not out of sight. If a new PE is to be developed from Lisp or Mesa, then other work on the existing systems must be kept to a minimum during this development (unless we want half the lab’s effort to be devoted to PEs), and they must be phased out as the new environment becomes viable. There doesn’t seem to be any reason to attempt a multi-language PE, since an environment with all our ABC features would support any existing style of programming, while a two-language system would require more work, reduce synergy, and create artificial barriers. Our problem, then, is to decide whether we want to pay the price for a new programming environment:

agreement on what the starting point should be;

manpower to build the ABC features which are missing;

willingness of users to suffer substantial inconvenience in changing over.

We are clearly talking about a project on the scale of the Dorado, and we should give it just as much careful thought as we did the Dorado project. Lab-wide discussion, and written feedback, seem like appropriate ways to carry out this process.