van der Poel: You are using, without real definition, many terms which I just don’t understand.
Perlis: The entire description could be phrased entirely in LISP, in which the ‘plex’ is a ‘function’, the ‘data’ is a ‘function’, the ‘structure’ is a ‘function’, and the ‘algorithm’ is another ‘function’. A ‘component’ is another pair of functions, which operates on complexes of list structures which are built up out of primitives. My interpretation is that when Ross uses terms like ‘ideal’ and ‘model’ and so forth, he is really talking about a specific mechanization of the process of representing complex storages in terms of elementary ones, complex algorithms in terms of elementary ones, and so forth.
In van der Poel’s paper there is a five or six line program describing an assembler. Now the question that we, as people interested in software engineering should ask ourselves is this: Is that five-line program the guts of our business or is it not? I personally feel that it is not — it is just part of it. The issue of building an assembly program goes far beyond that five line description. The description is an essential beginning, and is in a certain sense no different from what Ross has talked about so far.
Ross then went on to give a detailed description of a data structuring package built using his concepts illustrating techniques for selecting alternate mechanizations of ordered relationships in an automatic fashion.
Fraser: There is a practical problem here. It seems to me that in order to realise anything like this you have to do all your binding at run time. Is this true or have I missed a neat dodge somewhere in your AED system?
Ross: The neat dodge is some four to five more years of work on the compiler. Many things that now involve run-time action can be resolved beforehand with a more fully developed system.
Ross: Let me turn to software technology, and take the problems of banking as an example. In such a situation you would make a set of integrated packages, or as I call them ‘semantic packages’ each covering a major area of your business, and in terms of which you could describe, albeit abstractly, the entire process of banking.
Each integrated package is a sublanguage — the question is how to process it in a systematic way. My model of the communication process consists of:
1. Perform lexical processing of the input string (for example, recognising items from character strings)
2. Perform syntactic and semantic parsing of the input string
3. Build a model of the implications of the information transmitted by the input string, i.e. understand the information
4. Act on the information (for example, reply to the message). One therefore makes an idealised plex for each of these four phases for each semantic package, and then provides a mechanization of the plexes, interlocked to provide one cohesive and comprehensive language and system for banking problems.
Perlis: I wouldn’t build a banking system this way. The model that you are using is too sequential. I would start with Simula and build a simulation model of an abstract ‘banking machine’, simulate information flow on it, and gradually make it more detailed. I would choose Simula because it has facilities which enable me to construct and meter processes all at the same time.
Ross: Fine. But the only thing that is sequential is the communication process itself for each of the sublanguages. Simula would be just a different example to use instead of banking for my discussion. I think Simula’s success stems largely from the fact that it already incorporates many of these ideas.
5.3.3. PERFORMANCE MONITORING
The provision and the use of facilities for monitoring system performance is of importance in all stages of system manufacture. In fact both Section 4 (Design) and 6 (Service) also deal with the subject.
A concise description of performance monitoring in production was provided by Opler, and is reproduced here in its entirety.