5) describe variables and functional relations for on-line display.
Galler: Question to Graham: The Multics system of Project MAC was very carefully designed. Was it simulated?
Graham: No, the designers did not believe they could find adequate mathematical models. The decision was not really made consciously.
Haller: There is a special problem in simulating highly parallel processes on a sequential machine.
Wodon: A general point: the amount of simulation is a reflection of the amount of ignorance.
McIlroy: I feel attracted to the simulation approach. But is it not as hard to write the simulation model as the system itself? What about writing the actual system, but starting with dummy modules?
Randell: You have to go pretty far down the design process to be able to use dummy modules. Simulation should come earlier, even at the gross level.
Perlis: I’d like to read three sentences to close this issue.
1. A software system can best be designed if the testing is interlaced with the designing instead of being used after the design.
2. A simulation which matches the requirements contains the control which organizes the design of the system.
3. Through successive repetitions of this process of interlaced testing and design the model ultimately becomes the software system itself. I think that it is the key of the approach that has been suggested, that there is no such question as testing things after the fact with simulation models, but that in effect the testing and the replacement of simulations with modules that are deeper and more detailed goes on with the simulation model controlling, as it were, the place and order in which these things are done.
4.3.4. HIGH-LEVEL LANGUAGES
The use of high-level languages in writing software systems was the subject of a debate.
d’Agapeyeff: (from Reducing the cost of software)
»In aiming at too many objectives the higher-level languages have, perhaps, proved to be useless to the layman, too complex for the novice and too restricted for the expert.« I maintain that high-level programming languages have, to this extent, failed.
Fraser: Software is generally written in a low-level language. Has anyone written low-level software in a high-level language? Would you do it again?
David: (from Some thoughts about the production of large software systems (2))
»Few large systems have been written in high-level languages. This is not surprising since there are inevitable penalties in size and performance of compiled code, and these factors have been paramount in people’s minds. In my opinion, this view is no longer appropriate in many instances since techniques are available to overcome these penalties. Secondary memories can take the squeeze out of the size issue, and performance can be brought to a high level with the aid of a traffic analysis of flow of control in the system. Thus, those modules crucial to performance can become the subject of special attention. Indeed, the vast range of programmer performance indicated earlier may mean that it is difficult to obtain better size-performance software using machine code written by an army of programmers of lesser average calibre.
The advantages of coding in a high-level language lie in increased programmer productivity, fewer bugs in the code, fewer programmers required, increased flexibility in the product, ‘readability’ of the source code (‘self-documentation’) and some degree (unspecified) of machine independence (better called ‘portability’). Many of these advantages have a face validity, which is fortunate since they are difficult to support with hard evidence. There is evidence, however, on the flexibility issue drawn from the Multics experience. Multics is coded almost entirely in a subset of PL/l known as EPL. The early versions of Multics were large and slow. Major improve