Editor's~Note: The following article will be published in two parts.

Part 2 will appear in a later issue

of the COMMUNICATIONS.

T H E P R O B L E M OF P R O G R A M M I N G COMMUNICATION
WITH CHANGING MACHINES

A PROPOSED SOLUTION

Report of the Share Ad-Hoc Committee on Universal Languages

By J. STRONG,North American Aviation J. OLSZTYN,General Motors Corp.
J. WEGSTEIN, Bureau of Standards O. MOCK, North American Aviation
A. TRITTER, Lincoln Laboratory T. STEEL, Systems Development Corp.

I. BASIC ASSUMPTIONS.
One of the fundamental problems facing the computer profession today is the considerable length
of time required to develop an effective method of communication with the machine. Moreover,
it seems that the ability to communicate easily is no sooner acquired than the language changes,
and the problem is renewed, usually at a higher level of complexity.
A. Obsolescence of Machines. Experience would indicate that there are few machine users who do
not obtain new and different machines every three to five years--a change generally prompted
by technical obsolescence rather than by the decaying ability of the machine. In most cases,
the appearance of a new machine coincides with the necessity to expand computing capacity.
Although the programming cost involved in changing machines is high, the pressure to advance
to these new machines has been sufficiently great to justify their acquisition.
B. C-rowing Sophistication of Machine Languages. So far, each advance in machine design has been
accompanied by an increased complexity in the structure of its language, making programming
in machine-like language progressively more costly in both dollars and elapsed time.
C. Ezisting Compilers. Current compilers alleviate the problem somewhat by translating some par-
ticular "easy-to-code" language into a specific machine code. The principal shortcoming in this
approach is the considerable lapse of time between the initial conception of the "easy-to-code"
language and its general acceptance. This time is of the same order of magnitude as the machine
replacement cycle, resulting in the ever-present danger of having a good compiler available for
the old machine just after it has been replaced.

II. APPROACH TO A SOLUTION.

Let us examine a broad set of specifications which might describe a "system" capable of solving this
roblem.
• Ideal Specifications.
1. The individual with a problem would describe its method of solution in the language most
natural to his way of thinking about the problem.
2. Once his problem has been coded in this language, the solution might be obtained by processing
the program with acceptable efficiency on any present or future computer. (Efficiency of
operation in a proposed system is equal to the lowest possible total cost, including program-
ming, divided by actual total cost.)
3. A minimum of "system programming" should be required to produce the system initially
and to maintain it. Mosti installations should not be required to do any system programming
at all.
The ideal specifications listed above need some interpretation. In their
heY ma Y be incaP able of realization in this century
~. A few q ualifications

I2
 1. Saying that the man with the problem should speak in the "most natural" language is mis-
leading. His native tongue, English, is capable of almost infinite shades of meaning. Few
people can use English precisely and unambiguously. Consequently, the most natural method
of expression will have to be compromised in the interest of precision. This is not unusual;
almost every scientific discipline, and most trades and professions, have their own unique,
fairly precise language.
2. The ideal of processing every problem in every language on every computer and producing
efficient results can probably be realistically approached without too much compromise by
permitting the following conditions:
a. The coder can achieve higher efficiency if he knows which specific computer his routine
will be processed on.
b. Any routine written for a small computer may be processed on a larger one. However,
a routine written for a larger computer might be capable of execution on only a few small
computers and certainly not on a computer several orders of magnitude smaller. For
example, 709 routines would not normally be translated into E101 language since they
might run for many years on the smaller machine.
c. A large computer is available for development of the system. A run on a large computer
would prepare the system for all subsequent use on a small computer.
d. Although the existence of the system may influence computer design, the system should
not be dependent on this factor. Moreover, it would be undesirable if the system should
in any way inhibit the development of more powerful computers by restricting the com-
plexity of their basic languages.
3. With regard to the time required for system programming, one would hope that some
useful results of the system would be available in from three to five years. The design of
the system should not rely on a major "breakthrough" in programming art. The system,
for example, should not stand or fall upon its ability to develop a routine which is so
general that it can transform every type of language into every other type.

III. FURTHER ASSUMPTIONS.

The proposed solution to the problem will be presented in some detail in paragraph 5 below. Since
some of the assumptions underlying this solution may be considered controversial, a preliminary
discussion of them here may help clarify the final proposal.
A. Languages.
1. I t is impossible to agree on one universal POL. Since there are many varietie~ ~lemS,
any attempt at universality of problem-oriented languages will result either i ~uacy,
(such as an attempt to use algebraic language for a logical problem) or such "eness
as to become useless. In the latter case, the "universal" POL is re~dly ssible
POL's and is never truly universal for long, since the language mus t h the
new classes of problems that arise. ,
2. Machine languages will continue to grow in complexity and will becoI ~ ~icult
to code in. Everyone looks with dread a t the possible computers of~] ~hich
will be simultaneously executing ~aultiple [Link] stored proj,~ little
reason to expect a reversal of this trend.
3. The present status of the compiler art requdres a rather difficult gene'~ o trans-
form each POL formulated into each ML desired. Moreover, additk nust be
written whenever it is necessary to produce a different M L fl'om the one belon ; to t:he
machine on which the translation routine is executed. The; number of individm ' :t pmpilers
of the qmrrent type needed can only [Link] as it ]becomes desirable for P0L s Lultiply,

The
 B. Programming.
1. At the present state of the programming art, a reasonably efficient routine can be written
to transform any one specific language into any other specific language.
2. The complexities of the language transformed determine the size of the machine needed
for an acceptable degree of efficiency in both the transformation process and the subsequent
execution of the ML routine.
C. Machines. There will be available for the system programmers a machine at least as complex
as the IBM 709 and machine language programming tools at least as versatile as the SHARE
709 programming system.

IV. SOLUTION--THE THREE-LEVEL CONCEPT ("UNCOL").

A. History. This concept is not particularly new or original. It has been discussed by many inde-
pendent persons as long ago as 1954. It might not be difficult to prove that "this was well-known
to Babbage," so no effort has been made to give credit to the originator, if indeed there:wa~a
unique originator.
B. Outline. The system is composed of three levels of language, as shown in the schemati~diagram,
Appendix B.
1. ML Level. The lowest level (closest to the bits in the machine hardware) is composed of all
the current or future ML's.
2. POL Level. The highest level (furthest from the machine) is composed of all the current
and future POL's.
3. UNCOL Level. The center level is a single language "UNCOL," the Universal Computer
Oriented Language.
4. Generators. Generators are those routines which perform the transformation from the
POL's to UNCOL. They are analogous to present generative compilers except that they
produce, not a number of ML's, but only UNCOL. As with present compilers, one of these
would be needed for each POL used with a given machine.
5. Translators. These are routines which perform the transformation from UNCOL to ML,
and are like present compilers in that they are one-time preprocessors before execution of
the customer's program. However, they are not so complex nor so difficult to write as the
"generators" described above, since UNCOL, being computer oriented, has m a n y things in
common with each of the ML's. For each machine only one translator need ever be pro-
duced, regardless of the number of POL's formulated or used.

Y. CONCLUSIONS.
It might seem that the UNCOL three-level system does nothing but complicate the current method,
whereby compilers enable one to proceed with direct simplicity from a chosen POL to a specific
ML. Such is not the case. The versatility of this system is almost unlimited. Because of its com-
plexity, detailed discussion of UNCOL has been found to require a special flow chart notation (de-
scribed in Appendix B). With the addition of this notation, illustrative examples of how this system
might function are presented in Appendix D. Conclusions are summarized below.
A. Definite Immediate Benefits.
1. As each new machine is produced, all that would be necessary in the way of system program-
ming is a single translator to convert UNCOL into the new ML. The machine manufacturer
would probably write several successive versions for each of his machines in an attempt to
exploit to the fullest the outstanding features of each machine.
2. As each POL is invented, a system programmer must write a generator to translate his P0L
into UNCOL. Thereafter, his POL will never become obsolete. Routines written in it can be
executed on any machine a t any time in the future.
its current programs on any machine

md installed within three years. The

14
M

lS
 above a d v a n t a g e s can be achieved without requiring a major breakthrough in programming
techniques.
5. System p r o g r a m m e r s will probably work most of the time in UNCOL with only occasional
descents t o t h e ML level. A large percent of the customer's problems will be coded in one
or a n o t h e r POL. If, however, no POL is suitable, the problem can be coded in UNCOL
directly.
B. Growth Potential. Although the following potentialities exist, they are independent of the ad-
vantages o f t h e UNCOL system listed above. That UNCOL provides for growth in this direc-
tion is an i m p o r t a n t extra dividend.
1. " B o o t - s t r a p p i n g " is a distinct possibility. By boot-strapping is meant the ability to adapt
the s y s t e m t o new POL's, machines (or even new versions of UNCOL) with a minimum of
human p r o g r a m m i n g . That is to say, the system can be to a large extent self-renewing, with
the s y s t e m routines capable of producing newer and better system routines.
2. Simple "'boot-strapping" will probably be available almost immediately. System programmers
writing i n U N C O L can use an existing translator to produce their ML system programs.
3. It is q u i t e possible that within five years programming techniques may permit writing a
"general t r a n s l a t o r " in UNCOL which, given the characteristics of machine "A", would
produce ( o n other machines) a translator that would convert from UNCOL into the ML
of m a c h i n e "'A".
4. The last a n d least probable step would be the development of the "general generator". This
routine, if g i v e n the characteristics of the POL and the machine it was to run on, would pro-
duce t h e g e n e r a t o r to translate the POL into UNCOL.
C. UNCOL Itself.
1. The first s t e p must be the development of UNCOL and its acceptance as a universal standard
by some significant part of the computing profession.
2. Since U N C O L would be computer-oriented, any POL could eventually be expressed in it.
3. The e f f e c t i v e n e s s of UNCOL will depend upon how easy it will be to translate from it into
each M L , w h i l e exploiting at the same time the advantages of the new machine concerned.
4. If the s c h e m e is successful, UNCOL I should have a life expectancy of ten to fifteen ye~ws
before a n y large revision is necessary. UNCOL II could be devised with the "general gener-
ator" i n m i n d . Any transition to UNCOL II could be accomplished everywhere by boot-
strapping techniques. Only one routine need be written.

APPENDIX B
UNCOL SYSTEM NOTATION
LANGUAGES r e f e r to the symbols and rules for using them as understood by a human being. This
is independent of the particular vehicle (and its local code) used to carry them
(e.g. punched cards, magnetic tape, etc.).
POL: A n y Problem-0riented Language, e.g. FORTRAN.
ML: B a s i c Machine Language for any particular machine. If accompanied by appro-
p r i a t e "input translators", ML can be extended to include "machine-like" languages
u n i q u e to a particular machine, e.g. SAP symbolic language for the 704.
UNCOL: U N i v e r s a l Computer-0riented Language. This is a standard language oriented
t o t h e requirements of general purpose digital computers. It must have at least
t h e i r characteristics of being able to express any computable problem.
( I n the general schematic diagram, Appendix B, and there only, languages are
s u r r o u n d e d by a rectangle D).
ROUTINES a r e sets of instructions arranged in proper sequence. They can exist in any language,
into another language. They are desig-

the solution to a problem. Normally

P:
16
 these are "customer's jobs" (e.g. payroll, aircraft performance, etc.) and can most
easily be written in a POL.
G: Generators. Those routines which operate on routines existing in a P 0 L and per-
form the transformation from one specific P 0 L to UNCOL.
T: Translators. Those routines which operate on a routine existing in UNCOL and
perform the transformation from UNCOL to one specific ML.
SUPERSCRIPTS The symbol for a routine carries a superscript, indicating the specific language
in which the routine exists, e.g. F O R T R A N (meaning that particular POL), UNCOL
(which is unique), or 704 (meaning that particular ML).
SUBSCRIPTS are used to designate the operation the routine performs. Normally there is no need
to use a subscript with P. However, G and T must have a subscript, denoting the
transformation that the routine performs. For example; the notation:

~LINOOL ~ 704_,7

denotes a translator which transforms a routine in UNCOL into the same routine
in 704 machine language. The translation routine itself is in 704 language.
MACHINES are denoted by a triangle, thus:

The number, preceded by R, at the apex denotes a specific machine run.

FLOW CHARTS indicate a machine run. All necessary routines and data are shown as input. The
output is also defined. Routines are shown inside the oval symbol: C ) - For
example, a conventional production run, #872, on an Electrodata 205 is shown as:

20,5"'

D, qy',q

I
The symbol 0 means "operating on". Therefore, the

"A Problem routine in 205 language and its CASE

appropriate RESULTS are produced.
17
Generators and translators operate on other routines (usually Problem routines) and produce the routine
in another language as output; for example, a 704 run #892 might be:

This means: "The Generator in 704 language operates (in the 704) on the Problem in F O R T R A N language
and produces a Problem routine in U N C O L language as output."
NOTE several rules which are useful:
(a) The routine which is being executed must have a superscript the same as the machine being used
for the run.
(b) The routine being operated upon must have a superscript the same as the first hal/of the subscript
of the G o r T which is being executed.
(c) Output is the routine that was operated upon with its superscript the same as the last hall o] the
subscript of the G or T which is being executed.

~8