ments were made by improving the EPL compiler (3 times), by capitalizing on experienced programmers’ ability to produce EPL code which compiles for fast execution (3-10 times), and by changing strategies in the system to optimize its performance (3-10 times). Important in this process was metering of the system performance. Some idea of the magnitude of the improvements achieved can be obtained from the following: the overall system was at one time well over 1 million words; this was reduced to 300,000 by the combination of measures mentioned above. Further reduction of as much as 100,000 more is thought possible. In certain modules of the system, the improvements to date can be documented by the following approximate figures:
Size Performance
Module Improvement Improvement Effort
Page Fault Mechanism 26/1 50/1 3 man-months
Interprocess Communication 20/1 40/1 2 man-months
Segment Management 10/1 20/1 1/2 man-month
Editor 16/1 25/1 1/2 man-month
I/O 4/1 8/1 3 man-months
These figures indicate that major changes can be made in the software without a massive effort. To me, this flexibility is an absolute necessity for software incorporating new concepts, since initial versions must undergo evaluation to reach a satisfactory state. In my opinion, this is true of any large software package — it must be coded so as to make evaluation easy.«
Barton: Processors for higher-level languages are written in higher-level languages now. Soon we will have conversational languages for this sort of thing. The thing is that people don’t program well. They need the best tools. All questions of efficiency can be handled by improving hardware and generalizing language. At Burroughs we found Algol very successful. Later, influenced by Simula, we thought you have to provide programmers with a still more convenient tool.
Haller: It’s not sensible to make software better by making hardware better.
(d’Agapeyeff: Agreed.
Graham: Multics is written essentially in a subset of PL/1 except for a very few basic programs. Whether we would do it again: yes. The advantages show up particularly in big projects, with complex tasks. We get increased productivity of programmers. The programs are more easily understood, hence we can move people around easier, or replace them easier. One cannot predict the best techniques in advance, hence there is a need to rewrite parts of the system on the fly, which is easier with a high-level language. The machine code produced is not as good as that of good bit twiddlers, but probably as good as that of the average programmer.
Ross: The AED system is written in itself. I am for using higher-level languages. In this way we really capture what the system is all about and carry it over to the machine. We can build into a higher-level language and related packages a higher level of knowledge than the average programmer possesses, hence the possibility of giving the programmer better programs than he would write in assembly code himself.
Perlis: We tried a formula manipulator based on Algol, using the compiler, but found debugging easier with low-level language. Compilers often do not interface well with machines. It’s unfair to say that you wrote a system in a high-level language when in fact you are using only very few features, whereas many things that you need are not there at all.
Randell: In debates like this most people agree on the benefits of high-level languages, but back in the field very few large projects use such languages. I believe the reason is that project managers, if left to make the decision, will decide on the basis of their own small world. They will seek to optimise the easily measurable figures on which they expect to be judged, and will aim to minimise core store used and maximise speed. They will ignore advantages such as portability, ease of recoding, etc., even though in the long term these factors may well be of paramount importance. If such decisions were made at a higher level of the organisation, the outcome would be very different.
This point was also made by Barton, in stating that part of system design is the design of a style which will permeate down through the organisation, quoted in section 4.4.