Automatically Programmed Tools 

for Automatically Programmed Tools.

For the direction of numerically controlled machine tools.

The first language to be an ANSI standard: ANSI X3.37.

From 1956 featured many advanced structure related and proto-OO concepts (ref Ross HOPL snippet)

Had PLEX structure:

"'reverse index register', data-and-program-structuring scheme (typed records with fields) [...]. The offset (in an instruction) with respect to a pointer (set into an index register) as the "handle" on some n-component element, selected one word of the "bead" (record). Even jump instructions were stored in components, so that one change of the index setting could radically change many aspects of program behavior, as well as data.

Related languages
APT => ADAPT   Subset
APT => AED   Evolution of
APT => APT II   Evolution of
APT => ATP   Extension of
APT => AUTOAPT   Implementation
APT => AUTOLOFT   Influence
APT => AUTOPROMT   Extension of
APT => CADET   Extension of
APT => Chingari conversational APT   Extension of
APT => COMPACT   Extension of
APT => Data-beads   Extension of
APT => DDL   Influence
APT => EXAPT   Extension of
APT => IFAPT   Extension of
APT => KAM   Strong, Influence
APT => NELAPT   Dialect of
APT => RAPT   Extension of

  • Ross, D. T. "Gestalt programming: a new concept in automatic programming" view details
          in [JCC 09] Proceedings of the Western Joint Computer Conference, San Francisco, Calif., 1956 view details
  • "APT - The language that commands machine tools" Am. Mach., March 9, 1959, p106 view details
          in [JCC 09] Proceedings of the Western Joint Computer Conference, San Francisco, Calif., 1956 view details
  • Ross, D. T. "The design and use of the APT language for automatic programming of numerically controlled machine tools" view details Extract: Introduction
    APT is an abbreviation for Automatically Programmed Tools. It is the name given to a technique for producing complex metal parts efficiently and reliably through the combination of modern data-processing and numerically controlled machine tools. A numerically controlled machine tool is a machine tool to which have been added servomechanisms and electronic control circuitry so that the motions of the tool will respond to numerically coded instructions on punched tape or some other suitable control medium. The preparation of the instructions which specify the machine motions required to produce a particular part is called "programming the machine tool," or "part programming." Automatic programming is a new technique, made possible by modern computers, in which the instructions are not given in detailed numerical form but in terms of English-like language convenient for people to use. Automatic programming also permits all the difficult mathematical computations associated with the use of numerical control to be performed automatically by the computer so that the job of the human part programmer is greatly simplified.
    The APT System is an automatic programming system for numerically controlled machine tools which shows great promise for providing a means for realizing the full potential of numerical control. The concept originated at the Electronic Systems Laboratory (formerly the Servomechanisms Laboratory), M.I.T., in a project sponsored by the Air Materiel Command, United States Air Force, but the development of a complete system for industry-wide use has resulted from a cooperative programming venture sponsored by the Aircraft Industries Association. Figure 1 shows the basic organization of the APT System programs and indicates the company assignments as of February, 1959. A number of additional companies have since joined the APT Project, and current work assignments are somewhat modified from that shown in the figure. Project co-ordination is now the assignment of the McDonnell Aircraft Corporation, St. Louis, Missouri. Previous papers have presented a general description of the APT System itself and the organization and history of the APT Project. This paper, however, considers the system as an example of computer application to an area which presents
    The APT System is an automatic programming system for numerically controlled machine tools which shows great promise for providing a means for realizing the full potential of numerical control. The concept originated at the Electronic Systems Laboratory (formerly the Servomechanisms Laboratory), M.I.T., in a project sponsored by the Air Materiel Command, United States Air Force, but the development of a complete system for industry-wide use has resulted from a cooperative programming venture sponsored by the Aircraft Industries Association. Figure 1 shows the basic organization of the APT System programs and indicates the company assignments as of February, 1959. A number of additional companies have since joined the APT Project, and current work assignments are somewhat modified from that shown in the figure. Project co-ordination is now the assignment of the McDonnell Aircraft Corporation, St. Louis, Missouri.

    Previous papers have presented a general description of the APT System itself and the organization and history of the APT Project. This paper, however, considers the system as an example of computer application to an area which presents some rather unique problems. It will be noticed that the APT System structure - - contains virtually all the current techniques of computer applications, including simulation through interpretive programming, compiling, assembly, language translation, complex calculations, and data-processing of many forms and varieties. This paper is concerned exclusively with the design of the English-like language which is used to operate the system. The organization of the presentation is not historical but is rather an attempt to illuminate some problems of special-purpose language design for a specialized computer application. Most of the techniques employed are not unique to the APT System, but in some respects, owing to the mixture of geometric, mathematical, and production-type problems, combined with the lack of computer knowledge on the part of programmers who will be using this system, the emphasis on various aspects of the design problem is somewhat different from that found in many other automatic programming systems.
    Extract: The Geometric Language
    The Geometric Language
    Language Design
    There are many considerations which influence the design of a language. The purpose of a language is for the communication of some idea, concept, or message from one source to another. In general, the parties at each end of this communication or language link-the sender and the receiver-have different characteristics. They operate in different patterns and prefer different ways of handling and presenting information. If a language is to be successful, it must offer a good match to the natural behavior patterns of both the sender and the receiver. In general, this is accomplished by operating the communication link in three segments. The first segment is a language form which is particularly adapted to the sender; the third or last segment is a language form which is particularly adapted to the receiver; and the middle segment is a translation procedure going from one language form to the other. From the point of view of designing languages, it is necessary to consider the over-all package of two languages and a translation scheme as one over-all system. Therefore, the final complete language package is strongly influenced by the characteristics of the sender and of the receiver and by the translation scheme.
    The preceding discussion has treated the language problem as the determination of the abstract structure of a mechanism for transmitting information. Another important influence is of course the medium, through which this information must pass, that is, the physical expression or representation of the language. From the three-part view of the language link, however, since translation is separated out, the transcription or expression of a language is merely one of encoding the various words which constitute the vocabulary of the language and of devising a suitable arrangement for representation of the relationships among the encoded words. Therefore the physical representation of the language is of considerably less importance than the selection of the vocabulary and the syntactical construction of the language itself. We shall concentrate primarily on the design of the language itself and leave the expression of the language for later treatment.
    In the case of the APT System, the language link which is of primary interest is that going from the human part programmer (the sender) to the simulated APT computer (the receiver). There are of course other languages going from the APT computer to the various machine-tool control systems (which for the purposes of this paper will be considered of minor importance), and a language from the APT computer back to the human part programmer. In general, however, it is preferable that there be essentially one language going in both directions between the sender and the receiver, so we shall concentrate on the problem of designing a language for expressing geometric and machining instructions which is convenient for the part programmer to use and which can be economically translated into terms which the APT computer can understand.
    What kind of a person will the average part programmer be? What kind of training has he had? How does he think about machined parts? These questions are important from the point of view of language design, since the final structure and format of the language must fit naturally into the framework of the part programmer's past experience and knowledge. This does not mean, however, that the language should be tailored to fit exactly with the thought patterns and ways of doing things which the potential part programmer now employs. To a great extent these patterns of behavior have been influenced, and, in fact, primarily determined, by the old methods for producing parts. Therefore what is actually desired is not a language form which will mirror exactly the existing techniques and thought processes but rather one which takes advantage of the improved capabilities of numerical control and automatic programming to increase the part programmer's capabilities and at the same time one which seems to be a natural extension of the already acquired skills. A properly designed language can serve to advance the over-all capabilities of the production process without appearing to be a radical and revolutionary departure calling for large expenditures of money and effort to put into practice.
    Part Description
    What, then, is a part, and how can we describe and produce it? A statement commonly heard in connection with numerical control is that a part must be "described mathematically," and this is, of course, true. But it is not true that a part must be described by a single mathematical expression. Most parts are, in fact, composed of a multitude of subparts, each described by a single mathematical expression, so that a major consideration of the language must be the description of how these subparts are interrelated to constitute the whole. Notice that this decision to consider the over-all part as made up of subparts is, in fact, one step in the design of the language, since it is by no means the only way to describe the part. This may be seen most clearly by recognizing that this is entirely a human's view of the problem, since the same part which the human considers to be composed of many subparts will be thought of by the machine tool as a collection of thousands of tool-center locations which are to be connected by straight lines.
    From the machine's point of view, the consideration of thousands of points, each one very simple, is much preferable to the consideration of fewer, more complicated, subparts. The information contained in the two viewpoints is essentially the same, but the human's view consists of much fewer units of ,much greater information density than the machine tool's view.
    Sub parts
    Granted that the over-all part is to be described as a collection of subparts, how are the subparts to be described? Certainly, we would choose to call subparts by their natural descriptive names when possible rather than use complete, complicated mathematical expressions. Thus, for example, it is more natural to say the word CIRCLE than to mouth X2 + Y2 = Re. In other words, the word CIRCLE is far more natural for the human to use and is completely equivalent to the equation.  But there must be more to describing the subpart than merely stating what kind of a thing it is. One must also be specific about where it is, how big it is, and what shape it has. It is at this point that the problem of a co-ordinate system for the description of the part enters the picture.
    In order to tie all the subparts together into a single total part, one basic frame of reference must be chosen. When such a frame of reference is chosen, then, of course, each subpart can be expressed in terms of that co-ordinate system. Once this is done for all subparts, the description of the total part is complete. But now the question arises: How natural is it to describe a subpart in the selected coordinate system? We will ignore the fact that many geometric curves and surfaces have a natural co-ordinate system in which the equations take the simplest form and will assume that the problem of translation and rotation of axes is no great difficulty. But notice that the word "describe" was used in the question-and used advisedly. "How natural is it to describe the subpart in the selected coordinate system?" The point to be made here is that, in general, there are a great many ways to describe a geometric surface or a subpart in addition to merely specifying the coefficients within its mathematical expression. Thus, although the simplest mathematical expression for a circle is to select the proper coordinate system and then write XZ + Y2 = RZ, that same circle may, in fact, be more conveniently described by saying that it is tangent to two lines, with a specified radius, or that it passes through three points, etc. Thus, with the realization that a distinction can be made between specifying the equation for a subpart and describing that subpart, a whole new area for language design is opened.
    In general, a part has only certain critical dimensions and subparts which must be precisely located and specified. The remainder of the subparts are in fact only connective tissue and serve to give strength to the part and establish and maintain the critical dimensions. In other words, if we look over the shoulder of the designer as he originally conceives the part, he will specify that a bearing plate of a specified size must go in one place and a strut or support of particular dimensions must go another place. Then, on the basis of these critical components, he will fill in the remainder of the design to satisfy requirements of lesser importance. This is not meant to imply that these latter subparts can be put in an arbitrary fashion, since each of them also is determined by design criteria such as strength of materials, producibility, and even aesthetics.
    By the time the design reaches the part programmer, he must follow exactly what the designer has specified. But the fact that the subparts were determined by first selecting critical components and then filling in between with other components has important implications for the language which is to be used to describe the part. In general, the most natural way to describe many of the components of the design is by their relationship to other components, because this is the way the designer determined them in the first place. Thus it is most likely that many lines will be specified merely to be tangent to two circles, and many circles will be specified merely to be tangent to two lines, Only a few critical components actually will be given by detailed coordinate-type information.
    Descriptive Terms
    The description of geometric components in terms of their relationship to other components calls for the use of names and descriptive modifiers. The basic components of a part which form the framework for description for the remaining components must be referred to many times. Rather than require the full description each time, it is much more convenient to give names to the basic components and refer to those components only by name in further definitions. In addition to names of components, however, it is necessary to be able to specify what kind of relationship one component has to another. Terms must be available in the vocabulary for describing geometric relationships such as tangency, intersection, etc., and additional descriptive modifiers must be available for distinguishing redundant cases. Thus, for example, two basic lines of a part might be called TOP and SIDE. If it is desired to describe a circle which is tangent to these two lines, with a specified radius, there are in fact four possible locations for that circle, and the desired case must be further described through the use of additional modifying words.
    Notice that here again a language-design decision has been made, since it would be possible to use a unique descriptive word for each single case to be encountered. Rather the decision is made to separate multiple cases through the use of compounded statements made up of descriptive relationship words and modifiers. This means that statements made in the language will be somewhat longer, but the vocabulary of the language can be made much smaller. Relatively few modifiers carefully chosen can be used to distinguish and describe a large number of cases. As long as the ideas represented by the chosen words are natural for the part programmer to use, the language is made much easier to learn and apply correctly.
    The basic outline of the geometric aspect of the language has now been established. Complex parts will be described as collections of component subparts. In general, only the basic components will be given in terms of coordinate-type information, and the remaining components will merely be described in terms of their relationships to the basic components and among themselves. Standard geometric names, rather than mathematical forms, will be employed wherever possible, and arbitrary names may be assigned to components for future reference. Before proceeding to a discussion of the non-geometric aspects of the language, let us examine briefly some of the implications of this method for describing complex parts.
    Perhaps the most striking feature is the minimization of numerical data. If full advantage is taken of the ability to define components in terms of other components, most of the numerical parameters required to complete the definition of the mathematical form of a geometric component are implicitly determined. This is appropriate, since most part-programming personnel are experienced in tooling, production, and metal-cutting, and extensive mathematical calculations would be quite foreign to their background and would make the language difficult and awkward for them to apply. Their training does, however, equip them well for the over-all geometric aspects of part description, so that the language constitutes a natural extension of their existing capabilities.
    Another implication of the language form which can lead to considerable savings in cost and effort is that, once the ability is present to define components in terms of basic components, the same facility can be applied to define them in terms of additional components which may have no actual physical significance with respect to the part itself. In other words, by using the language, geometric components may be introduced which have no physical meaning as far as the part is concerned but which are useful for constructing definitions for other components necessary for the over-all part description. The clearest illustration of this is the case of the many powerful constructions which can be performed by ruler and compass. Almost all drafting operations are performed using straight lines and circles, sometimes in very elaborate ways, and these identical constructions can be programmed in the language, using the many available definitions for straight lines and circles. Thus it is no longer necessary that precise scale drawings be prepared in which the draftsman carries out careful ruler-and-compass constructions. Instead it is possible to perform all these operations by statements made in the language. It is also of course possible to introduce into the language additional descriptive techniques which can be carried out mathematically by the computer but could not be performed in the drafting room.
    Design Changes
    A final implication of the geometric language is of great importance in accommodating design changes. If the components of a complex part are primarily defined in terms of their relationships to basic components, then a change in one of the basic components will automatically cause the appropriate change in all the other components of the part. In other words, if a part is described by the relationship among its subparts, then drastic changes can be made in the basic components without destroying the integrity of the part. All the intermediate subparts that serve as connective tissue between basic components will automatically change and distort to accommodate the new information. Even though the part may look considerably different, the fundamental design intent will be preserved.
    The basic idea of this feature of the language is made most clear if we introduce one additional feature which has not previously been described. Just as arbitrary names such as TOP and SIDE can be given to geometric components, arbitrary symbolic names may also be assigned to any numerical quantities as well. Thus it is possible to write a complete geometric description of a part, including both the basic components and the implicit subcomponents, using only symbolic quantities.
    Even the basic components may be defined in terms of the coordinate system, using symbolic names for all parameters and numbers. The resulting set of statements in the language then constitutes an algebraic description of an entire class of parts. By giving particular numerical values to the names which stand for numbers, an individual member of the class of parts is selected. When viewed in this light, the language features which were introduced on the basis of being natural and convenient for the human part programmer to use are actually of much more fundamental and far-reaching importance. A language of the type which has been outlined does not merely save a little drudgery for a few individuals; in actual fact it represents a sizable step forward toward an improved technology for the production of complex parts.
    Extract: The Tool-Motion Language
    The Tool-Motion Language
    Choice of Vantage Point
    In addition to describing the geometry of a part, the part programmer must be able to exercise control over the machine tool and the APT computer by means of the language. Here, again, although the primary language-design criterion is convenience for the part programmer, the over-all implications of the resulting language are of more fundamental significance. The specification of the size and shape of the cutting tool, as well as the control of ON-OFF auxiliary machine-tool functions, is carried out in terms of natural descriptive words. No new considerations need be introduced to handle these simple functions.

    The control of the cutting-tool motion introduces a language-design problem which is distinct from that of the geometric language. In the case of geometric description presented above, the vantage point from which the part is described is primarily the chosen co-ordinate system for the part. This vantage point is appropriate for the static description of the geometry, but it is not well suited to the dynamic description of tool motion. If the vantage point is shifted, however, from the basic part coordinate system to the tool itself, then essentially the same language philosophy can be employed to describe tool motion as is used to describe geometry. Just as the over-all part can be viewed as a collection of component sub parts, the over-all tool path can best be viewed as a sequence of subpaths. The problem of describing the over-all tool path then becomes one of describing each of the component subpaths in terms of a common reference system.

    In order properly to co-ordinate the tool motion with the geometric description, the basic frame of reference is, of course, the same coordinate system as was chosen for describing the part itself. Once again, however, it is generally most convenient to describe component subpaths by their relationship to other paths, or to the geometric description of the part, rather than the co-ordinate system itself. In general, only the initial tool position and the initial tool direction of motion are given in terms of the coordinate system itself. All remaining tool motions are specified by descriptive terms relating the tool path to the geometric description of the part.

    Motion Description

    There are many ways to describe the curvilinear motion of a cutting tool in three-dimensional space, but one approach stands out from all the rest as the most natural and convenient for the part programmer to apply. Since the basic description of the part itself is given in terms of the component surfaces which bound the part, the most natural way to think of tool motion is in terms of curves drawn on the surface of the part. One slight complication arises, however, owing to the fact that the cutting tool is not a point but is rather a geometric surface of revolution. Therefore, a new surface called the driving surface is introduced in addition to the component-part surface in order to complete the description of the curve. The viewpoint is that the tool is "driven" along the valley formed by the intersection of the part surface and driving surface, with the tool maintained tangent to both surfaces simultaneously. For example, the case of a ball-nosed cutting tool is exactly equivalent to rolling a marble along the valley or groove formed by the intersection of the driving surface with the part surface. Just as in the case of the circle tangent to two lines, there are four possible positions for the tool. Two of these are automatically eliminated, since the tool must obviously be placed on the outside of the part surface; but either side of the driving surface is possible. From the vantage point of riding along on the tool as it progresses around the part, the two offset cases are quite naturally described by the terms TOOL RIGHT or TOOL LEFT of the driving surface.

    The motion along the curve determined by a part-surface and driving-surface pair, which constitutes one component subpath of the over-all tool path, is terminated by encountering the driving-surface-part-surface pair for the next subpath. In general, when two curves intersect, the first curve cuts the second curve into two branches so that the part programmer must be able to describe which of the two branches of the new curve the tool is to follow. Since the vantage point for considering tool motions is the tool itself, the most natural designators for the proper branch are terms such as GO RIGHT, GO LEFT, GO UP, or perhaps GO EAST or GO WEST. It is normally assumed that the tool offset to the right or the left of the driving surface will be maintained for the new driving surface, so that the simple specification of direction of turning provides sufficient information to establish completely the new tool path. Additional terms for starting cuts and handling special situations such as GO TO and GO PAST are introduced to describe the desired relationship of the tool surface to the surface in question. GO TO, for example, means that the tool is to proceed until it touches the surface, whereas GO PAST means that the tool is to proceed through the surface until the trailing edge of the tool is tangent to the surface. In this way a language can be built up which is fully adequate for describing the desired tool motion in terms of the same geometric surface components used to describe the part.

    Just as in the case of geometric description, it is possible and sometimes very convenient to describe tool motions which have nothing to do with the actual production of a part. In the case of geometry, new lines and circles can be introduced to assist in the construction of a desired component subpart. In an analogous fashion, through the simple device of introducing the terms DON'T CUT and CUT into the language, it is possible to take time out in the middle of a description of actual cutting motion to cause the tool theoretically to maneuver through space (possibly crashing through actual part surfaces and holding fixtures!) and, once the tool has thus theoretically been positioned into the next desired location, resume actual cutting instructions. Just as the ruler-and-compass constructions can greatly expand the geometric description capabilities of the language, the use of DON'T CUT-CUT sequences can permit the programming of tool motions which are supposedly beyond the capabilities of the calculating programs of the APT computer. The most powerful application of these techniques comes about when they are combined, in that pseudo-surfaces having nothing to do with the part itself may be introduced and the tool theoretically moved along those surfaces until it reaches a desired point, and then cutting of the actual part with actual surfaces can be resumed. A clever part programmer can perform real artistry through the use of these devices.

    Principal features of the language have now been presented. Both the static geometric and dynamic tool-motion aspects of the language follow the same philosophy of description rather than detailed specifications. The language is a true language, permitting great depth of expression, and is not merely a coding scheme in fancy trappings. The same philosophy of free description may also be followed in combining the geometric and tool-motion aspects into one complete part-programming language. There is great latitude in the sequencing of statements. All the geometric descriptions may be made at the beginning of a part program, and all tool motions programmed in terms of that description. On the other hand, if it seems more desirable, geometric descriptions may be interspersed freely with tool-motion statements, so that it is possible to describe the part on the fly as it is machined. Throughout the part program, numbers may be replaced by literal symbols, so that an essentially algebraic description results. The language is easy to learn and natural to apply and is a natural extension of the capabilities of part programmers. Extract: The Written APT Language
    The Written APT Language
    With the outline of the part-programming language complete, we may now turn attention to the written form of the language. Although the programming for the APT system is applicable to any general-purpose computer, at the present time it has been coded only for the IBM 704 computer (with a modified version for the IBM 709). Therefore, the written version of the APT language has been arranged to suit the punched-card input to that computer. A number of compromises have been made to make the computer programming simpler, but all the basic features of the language have been preserved, so that the basic capabilities of the system have been compromised little if at all. A single word in the APT vocabulary, when translated into English, may consist of two words. In order to fit the construction of the computer, the two-word English equivalents have been abbreviated so that in all cases at most six letters, ignoring spaces, occur in each basic term. Spaces are ignored entirely so that separation between terms is indicated by a comma, and the symbols "=," "/," and "$" are used for major punctuation. The resulting format is sufficiently English-like to permit the language to be acquired easily and used with facility.

    With most automatic programming languages for computers, there are a great number of punctuation and statement format rules which must be learned and applied exactly in order for correct results to be obtained. The same statement of course applies also to the APT language, although in some respects to a lesser degree. But it turns out that, since the English equivalents of the APT terms are so natural, there are only a very few basic rules which must be learned concerning the placement of words in the statement structure. All the remaining rules may effectively be ignored, since, if a statement makes proper English sense, it will also match the rules of the language. This means that the only training necessary to learn the language is to learn the appropriate viewpoint for the geometric and toolmotion aspects of the language, learn the meanings of the individual words, and learn whether they go in the major or minor portion of a statement. Actually, even the question of whether a term goep in the major or minor portion follows a natural pattern as well, so that in essence the only requirement, in addition to-learning the basic vocabulary, is to "get used to1' the kind of statements which are gramrnatically correct. Figure 2, taken from the APT Part Programmers' Manual, shows most of the current vocabulary of the APT System grouped into classes, with indication of the proper placement in the APT statement structure.
    Extract: Current Improvements
    Current Improvements
    The preceding discussion has been primarily concerned with the language of the APT II System which is currently in use. The basic philosophy will continue to apply to future developments of the language, but a number of significant improvements are now being worked on. Although all these techniques represent growing sophistication of the APT System itself, from a language point of view some of them are simple extensions of the basic APT language, while others represent a departure from the strictly descriptive language into a language form which is more often associated with computer programming. Even though the new computer- like aspects of portions of the language may be more difficult for the average part programmer to master, there still is no substitute for the power and generality of computer-like logic and decision functions. In other words, in order to accomplish certain large and complex tasks efficiently, language forms which are more logical and mathematical in flavor are most appropriate. Even with the reservations implied by these statements, however, since the new forms of expression are well suited to the complex tasks which will face the part programmer, it is expected that a proficiency in these techniques will rapidly be acquired by those who can benefit from their use.

    One of the extensions in the language will be brought about by the completion of an APT 111 capability for programming by regions rather than by curves. A region programming system, based on the original M.I.T. research, has been actively under development by IBM and United Aircraft for some time, and it is expected that a system combining both the APT I1 and APT TI1 capabilities will be completed in the near future. Among the language modifications which will be brought about by this development are a considerable increase in the number of methods for defining surfaces implicitly as well as statement formats for describing entire regions composed of several component surfaces and bounded by other surfaces. Tool-motion instructions will also be modified to permit the specification of spiral or zigzag machining of regions. Another scheme for automatically machining entire regions, which, in contrast to the APT III approach, will permit the part programmer to have complete control over the entire tool path, will be made possible by the introduction of instructions for automatically modifying and indexing arbitrary symbolic parameters in a part program. In this scheme an entire family of curves over a region can be generated automatically by the successive modification of driving-surface parameters after each circuit has been completed.

    Each of these techniques, one in which the multiple tool paths are determined completely automatically by the system, and the other in which a convenient means is presented for generating an entire family of curves, will be of great assistance to the part programmer and of course will also result in more far reaching improvements as well.

    A macro-instruction facility is also under development. This technique permits collections of APT language statements to be grouped together and given a name. Associated with this name are any critical parameters used in the statements which are to be treated as variables. Once such a macro-instruction has been defined, the part programmer need merely give the name, specifying in a natural way what the settings of the critical parameters are to be for this particular instance, and the system will automatically introduce and set up the entire collection of statements. It will also be possible to establish "normal cases" for the parameters, so that only unusual settings of parameters need be specified. Diagnostic alarms may also be set as normal cases, so that, if through an oversight the part programmer should omit the setting of a truly critical parameter, the system will notify him of his error.

    The macro-instruction facility in the hands of an astute part programmer can add greatly to the capabilities of the APT System. For example, part-program segments representing intricate constructions with ruler and compass can be programmed once and for all and established as single macro-instructions, so that in effect new preprocessing formats can easily be built into the system. Here, again, although macro-instructions appear to be motivated only by the desire to make the part programmer's task easier, the long-range implications are more fundamental. It will be possible, for example, for macro-instructions to be written which automatically set up all the machine-tool parameters, tolerances, etc., which are representative of a particular grade or goodness of machining. Then the designer need merely say that a part should be a class A-1 part (i.e., certain types of tolerances should have certain values, feed rates should lie within certain ranges, etc.), and standardization of machining practice will be accomplished merely by the part programmer beginning the program with the macro-instruction called for by the designer. Through techniques such as this, macro-instructions can be used to insure a type of quality control over a large group of part programmers by lumping all the critical parameters into macro-instructions, the definitions of which can be modified only by someone at a supervisory level.

    Another development which is currently being pursued is the introduction of logical and jump instructions into the part-programming language. This facility will allow the APT System to make decisions and modify its behavior accordingly. For example, it will be possible to state that one set of APT instructions should be obeyed until the tool comes into the vicinity of some particular surface. When this happens, a new set of instructions is to be obeyed. Combining this feature with macro's and indexing of surface parameters can give very elaborate control over the machining of complicated parts, without knowing exactly beforehand the sequence in which events will occur. It will also permit quite easily the programming of roughing and finish cuts using the same part program with modified tool parameters.

    One final feature of the language which probably will be expanded in the future is provision for increased control over the functioning of the APT System itself. Statements of this type will permit the part programmer to interrogate the system, asking for summary reports on conditions in certain areas and, in general, collecting information from the system as it operates, which may be useful in the evaluation of the adequacy of a given part program. In addition to triggering printed output in the same APT language as is used to program the system, this control will also apply to the three-dimensional-perspective plot program. At the present time additions to the language are being completed which permit the part programmer to conveniently delimit, in the part program, various segments of the tool path as distinct pictures. Pictures may overlap or may be nested one within another, and, under the control of instructions contained in the part program, any or all of the pictures can be photographed with arbitrary settings of the perspective parameters of the plot program, so that over-all views or detailed enlargements to high magnification can be obtained from arbitrary viewpoints. These features will permit detailed checking of part programs in a convenient and reliable fashion without consuming actual machining time.

    There are, of course, many elaborations on the language which will be made in the future. A language committee has been formed within the APT Project for establishing new goals, collecting suggestions for language improvement, and, in general, insuring a healthy and logical growth of the language facilities of the APT System. Still farther in the future, experiments are now being carried out at M.I.T. in the development of more radical departures in language developments. An experimental translation scheme has been developed which is intended to permit the use of arbitrary written English language for part programming, with no special rules of punctuation or statement format. As developments along these lines continue, it becomes increasingly clear that for many purposes English-like languages are not in fact the most convenient form of expression. Just as musical notation, with the five-line staff, various types of notes, rests, sharps and flats, is a much more expressive language medium for music than English would be, in many cases the ability to draw pictures or make gestures and motions would be much more convenient for expressing design information. Techniques are now under investigation for the combination of handwritten sketches and gestures with English statements to provide a composite language form which, it is hoped, will be equal to the task of conveying design information to future descendants of the APT System. Extract: Discussion - includes discussion of Price's system
    DR. GORN:
    As you will have gathered from yesterday's panel discussion, I am interested in language design. Yesterday I called attention to the distinction between what I call "descriptive language" and "command language." The APT language that Mr. Ross described contains elements of both. In the programming example illustrated in one of the figures the initial settings of the tool system were given.

    Now those were commands, but later on he said that he could give symbolic names to points and then ask the tool to move along a line toward one of these points until it got to the intersection of a given circle. The specification of the intersection point was a use of the descriptive aspects of the language. Then Mr. Ross has a means of setting the values of a number of parameters, and these now determine the locations of the symbolically named points.

    Now the following question comes up: Suppose the parameters you put into the generalized program are such that the computer understands you to mean one intersection of a line and a circle when you thought you were indicating the other, and the machine tool comes around and does something you did not anticipate, possibly gets caught in its own works and breaks. Is there anything in the language that corrects errors of that sort?

    MR. ROSS:

    Well, we have means of preventing some errors. Any time it is possible to determine by mathematics that an intersection does not exist, the system will detect this and say so. I t is also possible, when you are aware that there is more than one intersection, to use words like NEAR and FAR to specify which one you mean.

    But this does not answer your question. We can, and do, put into the system checks that catch, not all, but many unanticipated errors. For instance, we specify that the machining may not proceed longer than a certain number of steps without a certain thing happening. So it cannot run completely to infinity; it only runs a tenth of the way there. On the other hand, you are never really sure that the language description that is presented to the system represents what the man has in mind. It may be that he has made a perfectly grammatical statement which will result in an ambiguous case and produce some part that is completely different from what he had in mind. This is where our perspective-scope plot programs come in, because you cannot check within the language itself whether he wants this one or that. Now, we do try, wherever we can, to recognize when redundant cases can come up and give the system the ability to ask which is the right one, or choose what it thinks is the best one, and inform the man that it has made a choice among redundant cases. We do check the tool path by pictures or by tabulation before we put a program on the machine. We also machine some test parts in styrofoam, so that there is no danger of a tool breaking from a programming error.

    C. D. RINKER (Bendix Aviation Corp.):
    I was wondering, out of all the infinite variety of surfaces that you might come across, how large is your vocabulary in the APT language?
    MR. Ross:
    That is a good point. The system itself is three-dimensional, so that all curves are described by intersecting two surfaces. Even plane curves are represented by intersecting a plane with the appropriate cylinder. The present system has all the quadric surfaces: ellipsoids, hyperboloids, cones, circular and elliptical cylinders-things of that sort. It also has what we call a "tabulated cylinder program,'' in which you give a sequence of points in space and specify a line direction, and it passes an aurora borealis through them. Then there is a mesh-of-points program which is not yet incorporated in the system but will be distributed within a very short time. There are also a number of special routines where you can describe things by collections of ellipses, parabolas, and matching tangents and by using various interpolating schemes.
    The point to be made is that, when we started out on this thing, we wanted to design a system that would work, regardless of what the surface is. I have never had more than three men working on this in my own group, so we could not see solving special problems for individuals. Just as with the language problem, the goal is to capture the essence-to find out what is really the basic structure of the problem.

    The system works on the basis of what we call a normal vector program and a directed distance program for each type of surface. These give (1) from a point on the surface, a unit vector perpendicular to the surface; (2) from a point in space, looking in a specified direction, the distance to the surface in that direction. Well, it turns out that with those two subroutines for a surface type, you can construct anything you wish. The hard part is solved essentially once and for all for a very wide class of problems, and all you do is plug in the kind of surfaces that YOU wish. If somebody has a surface that is not already there, they just have to write a normal vector and directed distance program, and they are in business.

    DR. GORN:
    I think a technical answer, from what Mr. Ross has just said, is that you can get any twisted curve that is algebraic.
    MR. ROSS:
    Of the fourth degree.
    DR. GORN:
    No, the fourth degree would be only the restriction to the intersections of quadric surfaces.
    MR. ROSS:
    Oh, yes, right. This also applies to the APT III region programming. Everything is done in terms of surfaces using normal vectors and directed distances.
    R. S. BURINGTON (Bureau of Ordnance):
    I am just curious. Have you worked this out for the case of one-sided surfaces, like a Moebius strip? -
    MR. ROSS:
    Well, I do not know that there will be any practical reason for us to go into it. I will say that, the way the program is written, it expects the normal vector to point to the waste side. So that in this case, if you put in a Moebius strip or a Klein bottle, you would be saying that everything was waste and that the system would just go roaring around in space and you would come out with nothing.
    DR. GORN:
    In that case, you have described a standard routine for the machine to get rid of all the material on hand.
    E. W. ROTHROCK (Chicago Bridge and Iron Co.):
    How is the conversion from the language of the programmer or draftsman made into machine language? Is this a binary or an analog computer?
    MR. ROSS:
    Well, we are of course working on the 701, so obviously it is digital; but actually the structure of the APT system involves two main steps: First, we use interpretive programming to simulate the APT computer and from that point on we forget about the 704. Second, we have full-blown language translation, compiling, assembling, and all that sort of thing, that goes from the manuscript language into the coding language of the simulated APT computer.
    Then the APT computer is nothing more than a binary computer with an interpretive routine, is that right?
    MR. ROSS:
    Yes, indeed. In fact, you can program the APT computer for operating on any general-purpose computer. It does not work very well on little ones because it is pretty big. But it is a digital computer, yes, though a specially designed digital computer. Instead of adding numbers together, it moves tools. APT II moves a tool along a space curve; APT III moves a tool around and around to finish off a surface, a region.

    DR. GORN:
    If I may be allowed to generalize that, any mechanical command language like APT is a computer. You can create it by designing it in hardware or by simulating it on any other general-purpose computer. And the translation programs are such simulation programs.
    MR. Ross:
    I think that your question is really: What does an APT computer look like? And it does not look like anything. We are hopeful that the system will be coded for other machines besides the 704. There is a modified version for the 709; we hope that there will someday be one for something like the 1105, for TRANSAC, and so forth.
    R. F. HAMAKER (Bendix Products Division-Missiles):
    A couple of years ago there appeared an article in Fortune magazine which described a design machine. In your discussion you said that you would like to move ahead into the area where you could allow a man to design by moving his hands. This essentially is what the design machine was. The operator sat in front of a console, and on a scope in front of him he had displayed the design that he was trying to arrive at. By manipulating dials or joysticks, he could change the design on the scope. Is the program that you are presently using fast enough to allow this essentially instantaneous feedback, and would you speculate on how much would have to be done to get from where we are now to this hypothetical design machine?
    MR. ROSS:
    That article appeared in November, 1956, written by George Price. And I did not get to see it until six or eight months later, when somebody called my attention to it. Price actually stopped by at my house one Sunday night, and we chatted about things. His push-button language was very similar to the Gestalt programming that I talked about at the Western Joint Computer Conference in 1956, where you have a manual intervention language. Well, we will have that too. But the main language will be one which will use a light pen on the scope.
    About five years ago, using the area-scanner part of the Cape Cod equipment (a photocell that looks at a scope), I wrote a little program for the WHIRLWIND computer that would keep a spot sitting on the end of your finger while you moved it arbitrarily over the face of the scope. This makes a very simple two-dimensional analog-digital converter. We do this now with little transistorized light pens. In addition to drawing curves freehand, you can essentially push buttons by pointing at spots on the scope. Now this is the form that the language will actually take; rather than being rooms full of equipment, it will be essentially a couple of scopes with light pens and a few push buttons. But to back it up requires all sorts of new, high-powered artificial-intelligence-type programming techniques. It will be quite a while before anything becomes practical, even from a research point of view, I think, because it is a very difficult area.
          in Proceedings of the 1959 Computer Applications Symposium, Armour Research Foundation, Illinois Institute of Technology, Chicago, Ill., Oct. 29, 1959 view details
  • Ross, Douglas T. "The design and use of the APT language for automatic programming of numerically controlled machine tools" pp80-99 view details
          in Proc. 1959 Computer Applications Symposium, Chicago view details
  • Ross, D. T. "A generalized technique for symbol manipulation and numerical calculation" view details
          in ACM Conference on Symbol Manipulation, May 20-21, 1960, Philadelphia, Pa. view details
  • Ross, Douglas T. "A generalized technique for symbol manipulation and numerical calculation", pp147-150 view details Extract: Introduction
    This project is engaged in (a) a program of research into the application of the concepts and techniques of modern data processing to the design of mechanical parts, and (b) the further development of automatic programming systems for numerically controlled machine tools. The project is a cooperative venture between the Computer Applications Group of the Electronic Systems Laboratory and the Design and Graphics Division of the Mechanical Engineering Department, and is sponsored by the Manufacturing Methods Division of the USAF Air Material Command through Contract AF-33(600)-40604.

    This work is a natural outgrowth of the earlier development of the Automatically Programmed Tool (APT) System by the Computer Applications Group. The APT System translates geometric description and production statements from a natural English-like language into any one of a number of numerically coded languages t h a t control the operation of numerically controlled machine tools. Current development of successively more powerful APT Systems is being carried out by the APT Project (25 member companies) of the Aerospace Industries Association. Work now in progress at MIT constitutes a program of basic research leading toward a man-machine system in which the human and computer can work together on creative design problems. Ultimately it is hoped that the output from the system can feed directly into advanced APT Systems to achieve a direct and automatic means for going from the conception of a part of the finished product.

    At this stage of development it is difficult to distinguish design problems from general problem-solving. Current efforts, however, are concerned not with problem-solving but with problem statement, since only by an effective means for problem statement and restatement can it be assured that the human and the computer are working on the same problem. The closer one approaches creative design problems, the more nebulous and incomplete is the human's own conception of just what the problem is that is to be solved. Therefore the project presently is attacking the areas of structuring of abstract problem elements, translation and compiling techniques, and language design.

    The language of the computer-aided design system will include hand-drawn sketches and physical manual manipulation of picture elements as integral parts of the vocabulary and syntax of the language, on an equal par with the written vocabulary and syntax.

    Light pens and light cannons (photocell devices which feed human-modulated signals from the output scope back into the computer) are being used for graphical language studies.

    The design process itself is being studied to determine those aspects that can potentially be aided by a computer system. Drafting and dimensioning are being studied, as well as selection of standard parts, and mathematical techniques for stress analysis and other computational problems. Techniques for the efficient computation of very large, complex problems are being developed in the framework of a revised APT System analysis.
          in [ACM] CACM 4(03) (March 1961) view details
  • Sammet, Jean E "1960 Tower of Babel" diagram on the front of CACM January 1961 view details

          in [ACM] CACM 4(01) (Jan 1961) view details
  • Ross, DT; and Rodriguez, JE "Theoretical Foundations for the Computer-Aided Design System" view details
          in [AFIPS JCC 23] Proceedings of the 1963 Spring Joint Computer Conference in Detroit SJCC 1963 view details
  • S. A. Brown , C. E. Drayton , B. Mittman, "A description of the APT language" view details Abstract: The APT (Automatically Programmed Tools) language for numerical control programming is described using the metalinguistic notation introduced in the ALGOL 60 report. Examples of APT usage are included. Presented also are an historical summary of the development of APT and a statement concerning its present status. Extract: Introduction

    The application of numerical control (N/C) to manufacturing has increased steadily in importance since its feasibility was demonstrated by MIT's Servo-mechanisms Laboratory in 1952. The introduction of the computer to assist in the preparation of the numerical control information has been a key to practical utilization of N/C for a variety of manufacturing processes. In contour milling, for example, it is often necessary to approximate a space curve by straight line segments (cuts) within a few thousandths of an inch. tolerance. To accomplish this one may require the generation of thousands of coordinate points lying on the curve (or within tolerance of the curve) and for each of these points a cutter-radial offset must be calculated to determine the cutter center path.

    A great number of computer systems have been developed for numerical control programming. Among these are APT, WALDO, AUTOPROMT, SPLIT, AUTOSPOT, AUTOMAP, etc. APT (Automatically Programmed Tools) is the most general and most widely used of these systems. The current APT system is presently available on one large scale computer and is being implemented on others. The APT system is in daily use in a number of manufacturing organizations.

    In this paper the development of APT is summarized, its present status is discussed, and its language characteristics are described.
    Extract: Historical Summary
    Historical Summary
    In 1955, a prototype APT system was coded for the Whirlwind computer at MIT to demonstrate feasibility.

    This rudimentary version required the programmer to specify the endpoints of each straight line cut to be performed by the machine tool. In 1957, member organizations of the Aerospace Industries Association (AIA), in cooperation with MIT, undertook further development of the APT system. As a result of this development, a more advanced system was prepared for the IBM 704 in 1958. This system, called APT II, relieved the programmer of the responsibility of computing successive cutter locations and enabled him to describe the curve in an artificial language resembling English. The APT system provided a language translator. This was the beginning of the APT language as we know it today, a language which permits the so-called part programmer to describe the part to be machined and the functions to be performed on that part.

    Several versions of APT II have been used successfully in production by many aerospace companies. A still more effective system, known as APT III, was produced for the IBM 7090 as a cooperative AIA project and was released in December of 1961.

    During 1961, realizing that the APT concept was practical, but that its capabilities and potential had been just barely tapped, the AIA established the APT Long Range Program. Armour Research Foundation (now the IIT Research Institute) was selected to assume maintenance and validation responsibility for the existing APT system, and to direct the future course of a long-range developmental program. At the same time, the APT system, which previously had been available only to AIA members, was made available to any American company or government facility which desired to participate in the program. Companies joining the APT Long Range Program receive the complete APT system, documentation, training, etc., and by participating, help to underwrite the cost of further development.

          in [ACM] CACM 6(11) (Nov 1963) view details
  • Bagley, P. R. review of Brown et al 1964 (APT) view details Abstract: By way of introduction, we quote the brief abstract of the paper and a few sentences of the body:
    The APT (Automatically Programmed Tools) language for numerical control programming is described using the metalinguistic notation introduced in the ALGOL 60 report. Examples of APT usage are included. Presented also are an historical summary of the development of APT and a statement concerning its present status.
    . . .
    With APT the part programmer can define tool shapes, tolerances, geometric definitions, direction of motion of the tool, tool position relative to controlling surface, and auxiliary commands. In addition, the part programmer can write computational statements, macros, and looping statements.
    The familiar "problem-oriented languages" of ALGOL, FORTRAN, and COBOL are aimed at computing values and manipulating data. The APT language is an interesting contrast to these because it is a problem-oriented language designed primarily to cause actions in the world external to the computer. The paper is one of the first attempts to specify in a rigorous fashion such a "real-world manipulation language." The rigor isn't impeccable, but the reviewer found no major faults. With the refinements suggested by the critical comments below, the manner of presentation might well serve as a model for describing similar languages."
    This reviewer cannot comment on the adequacy of the APT language for the intended job, other than to observe that earlier versions of it have apparently been in successful use for a number of years.
    The paper gives an (intentionally) incomplete description of the APT language. It is possibly for this reason that the description is not wholly understandable. For example, the APT "arithmetic transfer statement" (similar to the FORTRAN if statement) specifies three statement labels, but there is no explanation as to the conditions under which any specific one of these labels represents the next statement to be executed. The paper does not in general give enough information as to when various expressions or constructions are to be used. An annotated example of a short but complete program would have improved the paper immensely.
    The entries under the headings "semantics" are variously: 1) the syntactical construction redundantly expressed in English; 2) the purpose of a construction; 3) a broad definition of a construction; and 4) the circumstances under which a construction is used. This inconsistency points the way to an improved format for describing APT and other languages.

          in ACM Computing Reviews 5(03) May-June 1964 view details
  • Kelley, R A The production man's guide to APT-ADAPT American Machinist June 1964 view details
          in ACM Computing Reviews 5(03) May-June 1964 view details
  • Tonge, Fred M. Review of Ross 1960 view details Abstract: Among the shortcomings (according to the author) of current list processing, symbol manipulation systems are their inefficiency for numerical calculations, some of which are present in most problems, and the inability to express directly (at the machine implementation level) more elaborate structures than binary trees. A representational scheme is proposed involving e-component elements, called plezes, implemented through the

    reversed use of index registers. Discussion of coding techniques using this approach is followed by a simple example, a program for the Wang Algorithm in propositional calculus.

    If the development of these interesting ideas had stopped at the state presented in this article, they would be of value to the professional programmer but not to the typical user of list-processing languages, who relies heavily, and rightly, upon the total systems package and debugging aids within which his language is imbedded. However, later developments in this work have been reported [ see, for example, Ross, D. T. and Rodriguez, J. E., "Theoretical Foundations for the ComputerAided Design System," Proceedings of the Spring Joint Computer Conference, vol. 23, 1963) CR 5, 5 (Sept.-Oct. 1964), Rev 6316 ] . Readers interested in non-numerical uses of computers should become familiar with this work.

          in ACM Computing Reviews 5(06) November-December 1964 view details
  • Mittman, B. "Symbolic control - APT system for programming numerically controlled machine tools" (in French) Automation, 1965, 10(2), 76-81. view details
          in ACM Computing Reviews 5(06) November-December 1964 view details
  • APT Encyclopedia 1108 Multiprocessor System Reference Manual UP-4078 Univac Data Processing Division 1966 view details
          in ACM Computing Reviews 5(06) November-December 1964 view details
  • [IIT Research Institute] "APT Part Programming" McGraw-Hill, New York, 1967 view details
          in ACM Computing Reviews 5(06) November-December 1964 view details
  • Sammet, Jean E., "Roster of Programming Languages 1967" view details
          in Computers & Automation 16(6) June 1967 view details
  • Mangold, W. E. "Status of NC language standardization in ISO" view details
          in Leslie (ed) Numerical Control Programming Languages 1969 (PROLAMAT 69) view details
  • Sammet, Jean E. "Computer Languages - Principles and History" Englewood Cliffs, N.J. Prentice-Hall 1969. p.605. view details Extract: APT
    In 1952, the M.I.T. Servomechanisms Laboratory (subsequently renamed Electronic Systems Laboratory) worked on a project sponsored by the Air Force Air Materiel Command to develop an automatic programming system for numerically controlled machine tools. In 1955 a prototype system was coded for the Whirlwind to demonstrate feasibility. This early version was restricted to two dimensions but it allowed parts to be programmed in terms of straight lines and circles in a variety of ways. In 1956 the APT (Automatically Programmed Tools) Project was formed and in 1957 a groupof Aerospace Industries Association member companies formed a joint effort under M.I.T. coordination to develop a more capable system, and better versions were produced.

    A more advanced system (APT II) was prepared for the IBM 704 in 1958. This relieved the part programmer of the responsibility for computing successive cutter locations, and it enabled him to describe the curve in an artificial language with English words. A still more advanced system known as APT III was produced for the 7090 and released in December, 1961.

    In September, 1961 the Aerospace Industries Association selected the Armour Research Foundation of the Illinois Institute of Technology to assume maintenance and validation responsibility and to direct the APT Long Range Program. The latter was to be a research and development effort involving the continued application and extension of the APT system. Member companies were to receive complete current systems, documentation, and information as they were developed. Work continued under that plan, and APT has been implemented on many different computers.

    The APT system has three major sections. The first reads file program and does the necessary translation, compiles a sequence of numeric instructions, and does some geometric calculations to prepare the data in standard form. About 100 alternate geometric definitions are reduced to about 10 canonical forms. The second section interprets and controls the sequences of cutting instructions, and it computes the coordinate points through which the tools must pass to produce the specified part. The last section, known as the postprocessor, converts the control data into the proper format for a specific machine tool, compensates for machine tool dynamics, and adapts any previous generalized information to the peculiarities of individual cutting hardware.
          in Leslie (ed) Numerical Control Programming Languages 1969 (PROLAMAT 69) view details
  • Stock, Karl F. "A listing of some programming languages and their users" in RZ-Informationen. Graz: Rechenzentrum Graz 1971 18 view details Abstract: 321 Programmiersprachen mit Angabe der Computer-Hersteller, auf deren Anlagen die entsprechenden Sprachen verwendet werden kennen. Register der 74 Computer-Firmen; Reihenfolge der Programmiersprachen nach der Anzahl der Herstellerfirmen, auf deren Anlagen die Sprache implementiert ist; Reihenfolge der Herstellerfirmen nach der Anzahl der verwendeten Programmiersprachen.

    [321 programming languages with indication of the computer manufacturers, on whose machinery the appropriate languages are used to know.  Register of the 74 computer companies;  Sequence of the programming languages after the number of manufacturing firms, on whose plants the language is implemented;  Sequence of the manufacturing firms after the number of used programming languages.]
          in Leslie (ed) Numerical Control Programming Languages 1969 (PROLAMAT 69) view details
  • Sammet, Jean E., "Programming languages: history and future" view details
          in [ACM] CACM 15(06) (June 1972) view details
  • Sammet, Jean E., "Roster of Programming Languages 1972" 20 view details
          in Computers & Automation 21(6B), 30 Aug 1972 view details
  • Sammet, Jean E. "Roster of Programming Languages for 1973" p147 view details
          in ACM Computing Reviews 15(04) April 1974 view details
  • Stock, Marylene and Stock, Karl F. "Bibliography of Programming Languages: Books, User Manuals and Articles from PLANKALKUL to PL/I" Verlag Dokumentation, Pullach/Munchen 1973 47 view details Abstract: PREFACE  AND  INTRODUCTION
    The exact number of all the programming languages still in use, and those which are no longer used, is unknown. Zemanek calls the abundance of programming languages and their many dialects a "language Babel". When a new programming language is developed, only its name is known at first and it takes a while before publications about it appear. For some languages, the only relevant literature stays inside the individual companies; some are reported on in papers and magazines; and only a few, such as ALGOL, BASIC, COBOL, FORTRAN, and PL/1, become known to a wider public through various text- and handbooks. The situation surrounding the application of these languages in many computer centers is a similar one.

    There are differing opinions on the concept "programming languages". What is called a programming language by some may be termed a program, a processor, or a generator by others. Since there are no sharp borderlines in the field of programming languages, works were considered here which deal with machine languages, assemblers, autocoders, syntax and compilers, processors and generators, as well as with general higher programming languages.

    The bibliography contains some 2,700 titles of books, magazines and essays for around 300 programming languages. However, as shown by the "Overview of Existing Programming Languages", there are more than 300 such languages. The "Overview" lists a total of 676 programming languages, but this is certainly incomplete. One author ' has already announced the "next 700 programming languages"; it is to be hoped the many users may be spared such a great variety for reasons of compatibility. The graphic representations (illustrations 1 & 2) show the development and proportion of the most widely-used programming languages, as measured by the number of publications listed here and by the number of computer manufacturers and software firms who have implemented the language in question. The illustrations show FORTRAN to be in the lead at the present time. PL/1 is advancing rapidly, although PL/1 compilers are not yet seen very often outside of IBM.

    Some experts believe PL/1 will replace even the widely-used languages such as FORTRAN, COBOL, and ALGOL.4) If this does occur, it will surely take some time - as shown by the chronological diagram (illustration 2) .

    It would be desirable from the user's point of view to reduce this language confusion down to the most advantageous languages. Those languages still maintained should incorporate the special facets and advantages of the otherwise superfluous languages. Obviously such demands are not in the interests of computer production firms, especially when one considers that a FORTRAN program can be executed on nearly all third-generation computers.

    The titles in this bibliography are organized alphabetically according to programming language, and within a language chronologically and again alphabetically within a given year. Preceding the first programming language in the alphabet, literature is listed on several languages, as are general papers on programming languages and on the theory of formal languages (AAA).
    As far as possible, the most of titles are based on autopsy. However, the bibliographical description of sone titles will not satisfy bibliography-documentation demands, since they are based on inaccurate information in various sources. Translation titles whose original titles could not be found through bibliographical research were not included. ' In view of the fact that nany libraries do not have the quoted papers, all magazine essays should have been listed with the volume, the year, issue number and the complete number of pages (e.g. pp. 721-783), so that interlibrary loans could take place with fast reader service. Unfortunately, these data were not always found.

    It is hoped that this bibliography will help the electronic data processing expert, and those who wish to select the appropriate programming language from the many available, to find a way through the language Babel.

    We wish to offer special thanks to Mr. Klaus G. Saur and the staff of Verlag Dokumentation for their publishing work.

    Graz / Austria, May, 1973
          in ACM Computing Reviews 15(04) April 1974 view details
  • Ross, Douglas T "Origins of the APT Language for Automatically Controlled Tools" view details Extract: Influences on general languages
    APT Language naturally spawned features later found in general-purpose languages and software systems. "Macroinstructions" built move sequences to safely orient toward and PLUNGE into a workpiece, e.g.. Surfaces were both physical and logical in tool-path specification and cut calculation, so the programming language was "object oriented" -- with no room for "ref" or "pointers" -- only meaningful NAMES. To define geometry, NESTED assignments of Names TO Objects arising in ruler-and-compass-like constructions, presaged AED's "phrase substitution" -- allowing any expression of the CORRECT (OBJECT-)type to fit anywhere. (I.e. it's the "where"s that have the Correctness constraints! Only they allow and impose structure! N-component elements "cluster 'where's".) Names and expressions take on the type of their objects (that they join or create), so contrary to today's OO talk: Classes or types do not "have" operations at all; they have operators. As in mathematics, it is the OPERATORs OF a type that provide the OPERATIONs ON Objects of that type to yield a Result Object.

          in SIGPLAN Notices 14(04) April 1979 including The first ACM SIGPLAN conference on History of programming languages (HOPL) Los Angeles, CA, June 1-3, 1978 view details
  • Sammet, Jean E "Roster of programming languages for 1976-77" pp56-85 view details
          in SIGPLAN Notices 13(11) Nov 1978 view details
  • Allen, F. and Schwartz, J. review of Sammet and Lee HOPL conference end banquet excerpts view details Abstract: The ACM-SIGPLAN History of Programming Languages Conference held in Los Angeles on June 1-3, 1978, was videotaped and excerpts of the presentations are available on two tapes; these and two tapes from the banquet provide brief but penetrating glimpses of the people most involved in the development of the 13 languages covered. At the conference and in the proceedings these leading formulators of the history of programming languages describe how their language was developed -- the historical setting of the work and how and why decisions were made. The videotape excerpts provide a summary of these descriptions.

    After introductory remarks, Jean Sammet, the Conference and Program Committee Chairman, introduces the keynote speaker and "the third programmer of the first large scale digital computer, Mark I," Capt. Grace Hopper of the US Navy. Capt. Hopper describes the very early history -- combining personal recollections and technical observations. It is an excellent historical talk, precisely establishing the milieu existing in the 1940s and early 50s, when the concept of using a computer to create programs was just emerging.

    The FORTRAN presentation by John Backus emphasizes the importance of object efficiency for FORTRAN acceptance. He states that language design was never considered a problem; the real problem was to consistently produce object programs as efficient as hand-coded ones. The presentation captures the clear and unwavering focus of Backus's original team on that goal: a focus and dedication which characterized the direction of one of the most significant software projects in the history of computers.

    The controversies in the committee designing ALGOL 60 are re-enacted in miniature on these tapes. Alan Perlis describes the American contributions, concluding that ALGOL has Influenced all languages since that time. "It's the mother's milk of us all." Peter Naur describes the European contributions and the origins of recursion in the language. A lively floor discussion involving John McCarthy, John Backus, and Fritz Bauer ensues. The Algol 60 committee got involved in "academic log rolling" according to McCarthy who also points out that the committee decision not to consider implementation led to a language which was not implementable as a whole. It was assumed that "everyone was a gentleman and none would propose something he didn't know how to implement. However there was no guarantee the combination was implementable."

    The excerpt on the LISP lecture by John McCarthy emphasizes the features of the language and is an excellent description of its intellectual sources. Jean Sammet in presenting COBOL also clearly defines the influences on the language and how and why the choices were made in a series of committee meetings. These choices were very much colored by the decision to take "a short range composite approach good for at least a year or two."

    The tapes show how differently some of these important languages developed. According to Douglas Ross, APT evolved out of application requirements; by contrast, the major features of JOVIAL were developed in a few minutes, relates Jules Schwartz, its sole designer. Geoffrey Gordon tells how GPSS also grew from feedback from application users. SIMULA, developed by Kristen Nygaard and Ole-Johan Dahl, didn't even start as a programming language. Charles Baker discusses the development of JOSS, and Thomas Kurtz, BASIC -- intended to make learning to program analogous to learning to drive a car: by doing it.

    PL/I was the largest language represented at the conference. According to presenter, George Radin, much of the complexity and size is due to the necessity of defining the result of all operations on mixed types and to implicit typing. The excerpts of the presentations on SNOBOL by Ralph Griswold and APL by Kenneth Iverson establish the specific motivations for those languages: in both cases conserving human resources was considered very important.

    The conference banquet tapes contain anecdotes by the conference speakers and by master of ceremonies Bernard Galler. These entertaining historical asides and footnotes sometimes give more insight into the how and why things happened than the more scholarly analyses. For example, George Radin's story about the PL/I committee's ordering pizza -- the pizza had everything anyone wanted -- says a great deal about how the committee functioned when designing the language.

    These tapes constitute an important historical record. Unfortunately, the quality of the tapes is less than desired. They were not professionally produced and the picture quality is often quite poor. Still-photos by Robert McClure and Richard Wexelblat are used where the videotape is inadequate. However, the excerpts have been well selected by J.A.N. Lee, Jean Sammet, and Henry Tropp.

    In his summary Fred Brooks says that "the best thing about this conference is the character set." He also points out that the presentations on the languages designed by a committee emphasized the process, whereas the presentations on single-author languages emphasized technical issues. These tapes capture the factors that have made the history: the personalities, the process, and the technology. They are interesting now and will be invaluable to future historians of the pioneering period of language development.
          in ACM Computing Reviews March 1982 view details
  • Erickson, M. D. review of Ross 1982 view details Abstract: In Section VI of the History of Programming Languages (APT Session) Douglas T. Ross presents a chronological historical account of the develoment of the APT language and its impact on numerical control of machine tools. Mr. Ross is justified in being proud of the accomplishments made by himself and his associates during the period from 1956 to 1960. The author makes the important point that the APT language was developed without a theoretical basis for language design or implementation, and without the benefit of management tools for large, dispersed team programming efforts. Mr. Ross's paper has as its theme a framework (based upon four premises) that supplied the equivalent of a theoretical basis. This was indeed an accomplishment of significant proportion for that time.

    This paper is recommended for readers having an interest in the "roots" of APT or in a somewhat detailed (and welldocumented) case history of a language development project. The development of APT has had a profound effect on manufacturing automation over the last 20 years, and has enjoyed an extended lifetime without technical obsolescence. Indeed, more develoments like APT are needed to achieve productivity improvement in tomorrow's automated integrated factories.
          in ACM Computing Reviews March 1982 view details
  • Steel, T. B. review of Wexelblat 1982 view details Abstract: This compendium is a magnificent book, belongs on the shelf of every information processing professional, and should be required reading for anyone who is to be granted a degree in computer science. While the book purports to be the record of the ACM SIGPLAN Conference on the History of Programming Languages held in Los Angeles in 1978, it is rather more than just that. It is an impressionist painting of a longvanished world whose inhabitants created a structure that has a profound influence, not only today but well into the foreseeable future, on the way all our institutions, commercial, governmental, or academic, conduct their affairs. The languages used to prepare computer programs dictate in many respects the thought patterns of the programmers, the questions they ask their users, the difficulty of implementing particular algorithms, and thus to a considerable extent what actually gets done. Beyond that, while it is premature to predict detailed effects, the consequences to the next generation of being taught these languages in school are certain to be enormous. The volume under review presents an account of how this structure came to be the way it is as seen through the eyes of some of the individuals responsible.

    It is a difficult book to review adequately. One must ask if it conveys the same message to that vast majority of information processing specialists who were not in the business at the time of the events recounted as it does to those of us who played an active role in some of the developments as they happened. Judicious inquiry of younger readers of the book suggests that rather more of the informal flavor comes through than one might suspect at first. In that sense the book "tells it like it was," although some of the text makes it quite clear that programming language designers have the same kind of selective and prismatic memories that other people have.

    The plan of the book is straightforward. Thirteen specific languages were selected by the conference organizers, and the book contains, for each language: a formal paper; a transcript of the presentation; a transcript of remarks by a designated discussant; a transcript of a subsequent question and answer session; the full text of all questions submitted; a biography of the authors. In addition there is the full text of the Keynote Address presented by Captain Grace Murray Hopper, itself required reading, and a series of appendices, including summaries of each language.

    As stated in the introductory material on the organization of the conference, the criteria for selection of the languages to be included were: "that the languages 1) were created and in use by 1967; 2) remain in use in 1977; and 3) have had considerable influence on the field of computing." The 1967 cutoff was to insure at least ten years perspective. The result of applying these criteria was:

    ALGOL 60

    This general review cannot pursue the specific language chapters; that is a task for individual reviews elsewhere in CR. Some overall comments are in order, however. The formal papers are not simply personal recollections of the authors. An organized procedure was established to guide each author in preparing an account according to established historical practice, thus maximizing the archival value of the papers. It appears to have worked, for the authors systematically -- and in some cases, apparently, painfully -- searched for old records, letters, and memoranda. The vignettes that surface therefrom are fascinating.

    No one should be surprised that the accounts of the camel (designed by committee) languages, ALGOL 60 and COBOL, have a somewhat different flavor from the others. There is a gold mine for students of decision making processes in this book. The conference organizers are to be commended for providing two accounts of ALGOL 60, one from the American and one from the European point of view. The contrasting perceptions and the almost recursive discussion are both intriguing and delightful.

    This reviewer's one regret is that it was impossible to capture and document the conversations that occurred over the coffee cups and in the corridors. In summary, this is a superb book, a must for all computer professionals. It is also one of the very few records of a conference of any sort where the reader gets a feeling for what it was like to actually be there. This reviewer was there and reading this book almost four years after the conference brought back delightful memories with preternatural clarity.

          in ACM Computing Reviews March 1982 view details
  • Van Deusen, M. review of Wexelblat 1982 view details Abstract: The History of Programming Languages provides a glimpse into the language design process for thirteen important languages. Each language chosen had to have been designed before 1967, to allow historical perspective, and had to still be in use in 1977. The authors were invited because of their central positions in the language design efforts. FORTRAN is described by John Backus, ALGOL by Alan Perlis and Peter Naur, LISP by John McCarthy, COBOL by Jean Sammet, APT by Douglas Ross, JOVIAL by Jules Schwartz, GPSS by Geoffrey Gordon, SIMULA by Kristen Nygaard, JOSS by Charles Baker, BASIC by Thomas Kurtz, PL/I by George Radin, SNOBOL by Ralph Griswold, and APL by Kenneth Iverson. To provide some consistency among so many authors, language coordinators were given the responsibility of providing review and aid to the authors. The result is a work of amazingly high quality.

    The particular interests of the authors show in the variety of organization and emphasis found in the papers. John Backus describes the background of the FORTRAN project, some of the design decisions, the documentation and implementation. Alan Perlis emphasizes the many people involved in the ALGOL design, from before 1958, through the Zurich and Paris meetings, culminating in ALGOL 60. Peter Naur concentrates on the design decisions made between the Zurich and Paris meetings. The disagreements which surface in appendices to his paper make for fascinating reading. Kristen Nygaard describes the many changes which the design of SIMULA went through from 1961 through 1971, from SIMULA I to SIMULA 67.

    The book is not a dry history -- many statements seem particularly surprising in hindsight. John Backus says of FORTRAN, "As far as we were aware, we simply made up the language as we went along. We did not regard language design as a difficult problem, merely a simple prelude to the real work of designing a compiler which could produce efficient programs." Jean Sammet stresses with regard to COBOL, "We were going to recommend a short range composite approach good for at least the next year or two."

    The history of the technical decisions is particularly well researched and presented. Many ideas were taken directly from other languages, such as the separation of the data description and executable statements in COBOL, deriving from FLOW-MATIC. Some seemed to occur almost casually, such as Thomas Kurtz commenting on the design of BASIC, "Around 1960 or 1961, after a visit to the PDP-1 time-shared computer at MIT, I can clearly recall John McCarthy saying, 'Why don't you guys do time sharing?' Shortly afterward I said to Kemeny, 'I think we ought to do time sharing.' Kemeny responded, 'OK.' And that was that!" Other decisions stemmed from deadlocks, as Alan Perlis described, when a European member of the ALGOL committee declared "No! I will never use a period for a decimal point." The proposal from Joseph Wegstein for three levels of language calmed the situation. The ALGOL paper and appendices by Peter Naur present different views of the same experience. Even a project consisting of only two people can produce its share of excitement. Kristen Nygaard describes the shock of a switchboard operator at overhearing a violent argument between two men in a hallway. She was reassured that it was just Dahl and Nygaard discussing SIMULA.

    One thing which emerges from many of the papers is the deep involvement which a language design can elicit from its designers. John Backus and Jean Sammet both describe many late, long hours.

    But this book is not just a series of papers by knowledgeable authors. It is itself a history of the History of Programming Languages Conference held in Los Angeles in 1978. Jean Sammet, the General Chairman, describes how the conference was put together. There are many valuable ideas here for potential conference organizers. The Conference Historian, Henry Tropp, provides a historical perspective and suggests archiving of design papers. The keynote address is by Grace Hopper. Its transcript captures the qualities of innovation and humor which make her talks such an experience. The author talks are based on the papers, so there is much redundancy of material. The main value to be gained by the duplication is the opportunity to discover the human side of the authors, which comes out in the more informal relation to the audience. Jean Sammet brings down the house with her lament that students are not given more than a passing exposure to COBOL before they receive their degrees in computer science.

    The question and answer sessions were often as interesting as the talks. The book gives John Backus's answer to the question why the letters I through N were chosen to designate integers. The readability of these sections attest to the effort which Richard Wexelblat put into the editing of this volume. The History of Languages represents a tremendous amount of effort from a great many people, and is a book which programmers as well as language designers will find both instructive and enjoyable.
          in ACM Computing Reviews March 1982 view details
  • Ross, Douglas "CAD Timeline at MIT LCS" Online resource view details
          in ACM Computing Reviews March 1982 view details