Heading:

Second EPE report (section 2)

Page Numbers: No

Second EPE report (section 2)

Charter and History

The purpose of this report is to set forth the discussions and conclusions of the second CSL Programming Environment working group. The most active members of this group (those who attended meetings regularly and produced memos or other substantial input for the group’s deliberations) were:

Dan Bobrow
Peter Deutsch
Jim Horning
Butler Lampson
Roy Levin
Larry Masinter
Gene McDaniel
Jim Mitchell
Ed Satterthwaite (SDD)
Nori Suzuki
Dan Swinehart
Warren Teitelman

Many other members of CSL also attended some or most of the meetings and/or provided written material for the group.

We began with the conclusions of the first working group, reproduced here from their report:

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.

Our discussions focused on a number of areas in which we felt clearer understanding was needed before we could make a proposal to the lab as a whole about what to do in the PE area:

What are the key technical issues which arise from each of the possible starting points?

What differences in the ultimate system would necessarily follow from each choice of starting point?

How much effort would be required to reach various levels of result from each starting point? What people would be available to do the work?

What other non-technical and external considerations should play a significant role in our decision about what to do?

The group has been meeting once a week for approximately 3 months. We did not begin with a fixed idea of how long it would take us to reach satisfactory answers to the questions above. However, we feel that we now have sufficiently good answers to consider this phase of EPE activity finished: the next step is to make a final decision about the starting point, which will require discussion by the lab as a whole, and then get down to work on the EPE itself.

Introduction

Why does CSL need a new Experimental Programming Environment?

CSL’s impressive productivity over the last few years can largely be attributed to its continuing investment in tools for itself. Dorado is a good recent example. It provides new opportunities for research in many areas by removing hardware capability (speed, memory, address space) as the major bottleneck. For the next few years, our ability to conduct computer system experiments will be largely limited by our programming capabilities.

CSL currently has two major programming environments, Interlisp on Maxc and Mesa/Bravo on the Alto. Each of these has major limitations deriving from its history and hardware base that make it less than ideal for at least some CSL applications. The arrival of Dorados provides an opportunity to remove many of these limitations and provide a single programming environment for the entire laboratory.

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, Laurel, and KRL (the implementation part) were taken as typical of such experiments, but we believe that it will be important to conduct future experiments more quickly and at lower cost.

A programming environment is more than just a programming language. It is the entire system that is used by the programmer in the process of developing programs. As such, it will certainly contain such tools as text editors, debuggers, prettyprinters, etc. The underlying design principle is that the purpose of a programming environment is 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). Software bottleneck removal is the implicit justification for many features.

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.

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 the high-priority features on which we have agreed.

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 that 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.