languages develop, but if you want to get all the ideas in programming you could probably select somewhere between six and twelve languages and see all the ideas fairly well represented in this composite language. Now if one starts with a middle language, which sort of extracts the ideas of programming, and ruthlessly discards all questions of detail in style, such as precedence of operator conventions, then you can do two kinds of things with it. First, this forms the specification of a machine, though at this point we don’t know how much of that machine is going to be soft and how much is going to be hard. But some people can go away and work on it. But you can also say to people who are concerned with producing particular processors, where human preferences will get into the language: this is the target language you will work into; go away and implement in this language. Now if you are successful at this in between point you may have achieved the specification of a machine language that would be widely acceptable. If you haven’t been quite that successful, you will at least give the software designers who work with the initial machine a kind of minimum task to perform. They can consider this language as a tool they would use in the development of further languages. If you are successful in picking an in between point you will avoid the disadvantages of the propagation of undesirable features up or down.
Gill: I would like to add to my paper by pointing out that one of the problems is that many designers are aware of the danger of propagating features too far through their work and they overcorrect for this by deliberately suppressing hardware features which they think the user ought not to have to worry about. The user then finds that he has absolutely no way of controlling these aspects of the hardware.
Fraser: In the designs I have been involved in, and which have not involved too many people, I have not been able to identify whether these have been ‘top-down’ or ‘bottom-up’. They seem to me to be more like frame stressing, where one is trying to stress a structure with welded joints. You fix all the joints but one, and see what happens to the one, then fix that joint and free another and see what happens to that. It’s a sort of iterative process which follows an arbitrary pattern through the structure. Perhaps this only holds for small designs, with few people and good communications. About large designs, I don’t know.
Perlis: Fundamentally, the procedure you mention, which is ‘fit-and-try’, will work very well with three or four people. If you have a hundred people the ‘fit-and-try’ process diverges because of lack of control.
McIlroy: Talking about where one starts is, I think, perhaps a slight lie. One starts in fact with the grand conception, including the top and the bottom. One can see this in a conception like that of Algol 68. This starts with the top, which is the program, and the bottom, which is the word, the machine word. These are the two fundamental premises, everything else is fitted somehow in between. This is the way a designer starts on Day One. However, he has to do a very large job, and therefore he must structure it in some way. So now we come on the day after Day One to the issues of how to put on a structure.
Barton: In the beginning was the word, all right — [general laughter] but it wasn’t a fixed number of bits!
4.3.2. STRUCTURING THE DESIGN
The structure of the software resulting from the design process was discussed extensively. The background ideas are reported on partly in working papers reproduced in section 9: E.W. Dijkstra: Complexity controlled by hierarchical ordering of function and variability and B. Randell: Towards a methodology of computing systems design. Other background passages are given below.
Kolence: (from On the interaction between software design techniques and software management problems)
»A design methodology, above all, should be coherent. A design expressed in one notation should permit the various functions required to realize a design to be defined efficiently in terms of that notational description of the design. Software design notation, for example, should decompose naturally from the highest level of design description down to design documents which suffice for maintenance of the final software.
…
Other types of relationships should also be considered in making the choice of how to break a design apart and what potential problem areas are implied by any given design decomposition. Currently a software manager is greatly hampered by the use of fuzzy concepts about such things as data structures (particularly files and