AED(ID:217/aed001)
Engineering flavour of ALGOL
Automated Engineering Design (aka ALGOL Extended for Design).
A general purpose system based in Algol 60 with very powerful string and list processing facilities
MIT System Laboratory ca 1965 by a team led by Douglas T. Ross, and including J E Rodriguez (dataflow pioneer). Systems language for IBM 7090 and 360, an extension of ALGOL-60 with records ("plexes"), pointers, and dynamic allocation. DYNAMO II was written in AED, as was the first BCPL compiler.
Sammet 1969 and 1978.
Hardware:
Structures:
Related languages
| ALGOL 60 | => | AED | Extension of | |
| APT | => | AED | Evolution of | |
| AED | => | AED String Package | Extension of | |
| AED | => | AED-0 | Extension of | |
| AED | => | AED-JR | Subset | |
| AED | => | AEDNET | Extension of | |
| AED | => | BCPL | Written using | |
| AED | => | DYNAMO II | Written using | |
| AED | => | Rodriguez dataflow | Evolution of aspect | |
| AED | => | RSL | Incorporated features of |
References:
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
in [ACM] CACM 4(03) (March 1961) view details
in [ACM] CACM 4(03) (March 1961) view details
in [AFIPS JCC 23] Proceedings of the 1963 Spring Joint Computer Conference in Detroit SJCC 1963 view details
June 1964-November 1964: With stable Algol syntax, AED-0 language advances are made only semantically, with "Integrated Packages" of atomic and molecular functions. Virtually all of the features of what now are called abstract data types and object-oriented modular program structuring were covered, one way or another. Procedure bodies were defined separately from their declaration. Nesting a family of functions of a Package within an outer SetUp procedure, allowed the actual arguments of a SetUp call (and return) to parameterize the entire family, until the next such call. The most fundamental package provided Zone-Structured Free Storage management [nested zones can have individual dynamic strategies]; Data Structuring [String Package provided generic operations for stacks, queues, one- or two-way rings, arrays, hash-coded tables, etc., depending on specific Basic Functions selected]; Free-format I/O; Plex Dump-and-Relocate (of arbitrary data structures). Others were: BLEBR Stack Manipulation; DOIT for procedure data type execution; LDOIT for automatic dynamic loading of missing procedures; .C. character string data type (any character can quote all others; ".C.//" is standard); logical operations on bit words; PRESET data/bead values; ISARG optional arguments (many flexibilities on standard packages, including exception handling). AED Macro Preprocessor pass provides Synonyms, .INCLUDE. declaration files, and Compressed source files. Source-Language Debugger. Generalized Merge for system structuring at load time (command pipelining precursor). Kludge programming A-Core/B-Core System enhanced to allow rotatable nested subpictures, 3D pseudo-pen, automatic hidden restructuring of display files. Hardware: A dual Slave console was added.
External link: Page at MIT for this paper Extract: Meaning of PLEX
The Computer-Aided Design System is not intended to solve any particular class of problems, but instead should be applicable to essentially any area of design and problem-solving. In order to achieve this generality with a single comprehensive system requires careful attention to the fundamentals of solving problems with computers. Since the system is to be applicable to essentially any kind of problem, a single unified approach to handling the data and information about problems is required. Thus one of the early developments of the Project was the concept of a technique for not only containing all of the data about a problem, but also showing all of the requisite interrelationships among the individual items of data in what is called a plex structure.
"Plex" is derived from the word "plexus" which has a dictionary meaning "an interwoven combination of parts in a structure; a network". A plex is considered to be composed of elements of various types, each type of element having a number of components appropriate to the object or relationship which the element represents. Components of elements may contain data in numerical or coded form, or pointers to other elements. In application, the objective is to model all of the pertinent information about a problem in an elaborate plex structure so that all of the data and relationships are explicitly shown. If this can be accomplished, then any processing algorithm can obtain any information it requires by suitable referencing of the elements in the plex structure. Extract: Introduction
Introduction
Since 1959 the Computer Applications Group of the Electronic Systems Laboratory and members of the Design Division of the Mechanical Engineering Department have been working on the Computer-Aided Design Project sponsored by the U. S. Air Force. The objective is to create a man-machine system in which a group of designers and a computer can work together as a team on fresh design problems which require creative solutions. Since the concepts of time-sharing and dynamic man-machine interaction are inherent in the concept of Computer -Aided Design, this work is also being supported by Project MAC as an integral part of its general goals as well.
The Computer-Aided Design System is not intended to solve any particular class of problems, but instead should be applicable to essentially any area of design and problem-solving. In order to achieve this generality with a single comprehensive system requires careful attention to the fundamentals of solving problems with computers. Since the system is to be applicable to essentially any kind of problem, a single unified approach to handling the data and information about problems is required. Thus one of the early developments of the Project was the concept of a technique for not only containing all of the data about a problem, but also showing all of the requisite interrelationships among the individual items of data in what is called a plex structure.
Extract: Plex
"Plex" is derived from the word "plexust" which has a dictionary meaning "an interwoven combination of parts in a structure; a network".
A plex is considered to be composed of elements of various types, each type of element having a number of components appropriate to the object or relationship which the element represents. Components of elements may contain data in numerical or coded form, or pointers to other elements. In application, the objective is to model all of the pertinent information about a problem in an elaborate plex structure so that all of the data and relationships are explicitly shown. If this can be accomplished, then any processing algorithm can obtain any information it requires by suitable referencing of the elements in the plex structure. Figure 1 shows the modelling plex for a line in two-dimensional cartesian coordinate space. The elements contain type and name components, as well as pointers to show the end-point relationships, and places for storing the coordinate values. Any property of the line which is required, such as its length or its slope, may be computed by referencing the appropriate components in the elements of the modelling plex.
The concept of plex structures is well suited to the requirements for providing a firm foundation for development of the Computer-Aided Design System, since it is general, powerful, and may be mechanized in a great many ways on computers, but for any actual problem, the plex structures which arise are so elaborate and complex as to be essentially incomprehensible to humans. Thus a mechanism is needed for automatically transforming the ideas which a human designer may have about problems into the intricacies of the modelling plex.
The concept of plex actually involvee more than mere structure or form. There is no unique modelling plex for an object or a piece of problem in general. Instead the etructuring and choice of components is determined by the use which is to be made of the model. In other words - an inherent part of the concept of plex is the idea that processing algorithms will interpret the contents of the components and thereby ascl'ibe meaning or purpose to them. What the components represent depends very closely upon the algorithms which reference them.
Of great importance are the algorithms which describe the process whereby individual elements are assembled to form a complicated plex.
The vast complexity of a modelling plex never arises all at once, but instead is built up step-by-step by a process of accretion. The viewpoint is that special meta-properties are ascribed to the elements and these meta-properties control the behavior of algorithms which establish the step-by-step interconnection of elements to cause the growth of a large structure. The effect of individual elements being assembled by an algorithm into a large structure is as though the combination of the metaproperties and the algorithm gave behavioral properties to the elements themselves, so that the elements interact to form large structures in much the same way that chemical elements interact to form large molecules. In this short progress report we try to demonstrate how this abstract concept of plex as a mixture of structure and behavior can be applied to yield efficient and powerful mechanisms for solving the numerous problems involved in research on the Computer-Aided Design System. The technique has been applied within the Project in a great many places, but here we consider only the problems of verbal and graphical language and the compilation of efficient computer programs. Extract: Graphical Language
Graphical Language
It is of vital importance that the language facility for the Computer-Aided Design System include not only flexible descriptive and programming languages in word form, but a generalized capability for graphical communication as well. There are many aspects of design in almost any field, for which the natural means of expression is in terms of pictures or diagrams, and any attempt to convey equivalent information in verbal form would be extremely unnatural and awkward, and would defeat the basic principle that the designer-user be able to operate in a manner which is natural to him.
The ESL Computer Applications Group has been active in the field of on-line man-machine systems for over 10 years (the first tracking program was written in late 1954 for the Whirlwind Computer), but the first complete subsystem for graphical communication was the Sketchpad program of Dr. I. E. Sutherland, written for the TX-2 Computer at Lincoln Laboratory, with NSF and Lincoln Laboratory support, in 1962. This program is one of the outstanding success stories in the field of computer applications, for it made the concept of graphical communication with a machine come alive in a very meaningful way to many thousands of people.
Sketchpad and the plex concept which underlies the AED System share a common heritage. In late 1961 Sutherland had completed his first attempt at a light-pen drafting language, based upon the use of tables of points and lines, and push-button commands corresponding to standard drafting tools for drawing horizontal and vertical lines, slanted lines, circles, etc. At the same time the Project was independently beginning to apply the concepts of the Bootstrap Compiler to the consideration of graphical language and was beginning a study of a "Bootstrap picture language. At that time, the plex concept was thought of as almost purely structural, and although a preliminary version of the First-Pass Algorithm for programming languages of the Algol type had been devised in the preceding months, the strong relationship between interaction algorithms and structure was not then apparent. Still earlier, in 1960, the Project had carried out a "point-line diagram study" in order to gain experience with list processing techniques. This problem concerned techniques for constructing diagrams composed of points, lines, and angles, and imposing geometric constraints on the elements of the diagram in successive stages, as an example both of graphical language and as a model for the design process itself. The problem was carried out in the LISP system then being constructed by the MIT Artificial Intelligence Group and no attempt was made to drive the resulting programs with light-pen inputs. Instead the study provided impetus to the developments of the more general plex concepts, since it was felt that the storage and time expenditures inherent in attempting to model things entirely in terms of lists and trees wobld be impractical for a commercially feasible Computer -Aided Design System.
In early 1962, then, the interaction between the beginning First- Pass Algorithm and the Bootstrap Picture Language led the Project to the generalizations which evolved into the Algorithmic Theory of Language itself, while Sutherland, influenced by the structural aspects of the plex concept of that time, pursued Sketchpad proper. The Bootstrap Picture Language study as such was discontinued in view of the success of Sutherland's efforts.
With the successful on-line operation of the ESL Display Console on the Project MAC Computer, attention has now returned to the problem of providing graphical language capabilities on commercial equipment as a part of the Computer-Aided Design System. As a beginning the highly successful Sketchpad capability will be duplicated externally. The internal processing of the programs, however, will be almost entirely different from those used by Sutherland. Whereas Sketchpad was created on the TX-2 Computer through the considerable programming artistry of Sutherland using the TX -2 macro assembly system, graphical language for the AED System will be mechanized as a special application of the Algorithmic Theory of Language and plex concepts. Therefore, the original objective that there should be no distinction between verbal and pictorial language for the Computer -Aided Design System will be achieved.
In order not to interfere with the compiler developments of the Project, and in order to obtain a simpler base of programs to work from, while at the same time providing an experiment in dynamic man-machine interaction in a time -sharing environment, a simplified miniaturized version of the over-all Computer-Aided Design System has been written.
Although not yet officially christened, this little system will be referred to as AED Jr. in the following description of how it has been used to prepare a preliminary demonstration of Sketchpad capabilities within the over-all AED framework.
AED Jr. consists of a master control program and a number of sub -programs for setting up the meta-properties of new vocabulary words, examining the vocabulary table entries, making corrections, running statements through the First-Pass Algorithm, and examining the syntactic structure in the form of the parsed tree, and checking the correctness of the precedence string which models the semantic structure of statements.
All of these features are directly under the control of a simple command language which may be typed on the teletype, and included among these commands are commands to accept input statements from the light pen and push buttons of the ESL Display Console and to plot graphical statements on the console. In the following description characters printed by the system are in upper case and characters typed by the user are in lower case. We describe the features of the system by illustrating how a trivial language consisting of the words begin, -- end, and - fini may be inserted and tested, and then give some illustrations of the results of the more elaborate graphical language used for the May 6th demonstration.
in [AFIPS JCC 23] Proceedings of the 1963 Spring Joint Computer Conference in Detroit SJCC 1963 view details
in [ACM/IEEE] Proceedings of the SHARE design automation workshop 1964 view details
in ACM Computing Reviews 5(06) November-December 1964 view details
This edition is a major revision and extension of the first, to incorporate the changes to the (CTSS) Compatible Time-Sharing System during the past two years. The manual itself is organized into sections for easy referencing and to facilitate future expansion and modification. The manual is maintained on-line within the system in an attempt to keep all system documcutation continuously up to date. A system user can keep his manual updated by periodically inspecting a table of contents and requesting an on-line printout of those sections which have been revised since he last updated his copy.
Some features of the CTSS which are detailed in this edition are: password logic, introduction of more elaborate accounting features, inter-console message, public files, and macrocommands. A new file system was implemented to remove some previous weaknesses and to test a prototype of the file system which is proposed for the next timesharing system.
Available languagcs and subsystems include AED (modified ALGOL), BEFAP, COGO-90, COMIT, DYNAMO, ESL DisplaySystem, LAPC, GPSS, MAD, T\IADTHN, SNOBOL, STRESS, and BLOW (BLODI Diagram Compiler). The manual presents a brief description of general subroutines and a description of commands for the creation, editing, compression, printing, and housekeeping of files, program execution and debugging.
in ACM Computing Reviews 5(06) November-December 1964 view details
in Sass, M. and W. Wilkinson, eds. Computer Augmentation of Human Reasoning Spartan Books, Washington, D.C., 1965 view details
in [ACM/IEEE] Proceedings of the SHARE Design Automation Project Annual ACM IEEE Design Automation Conference 1965 view details
About one-half of the prototype experimental system was programmed using the Automated Engineering Design (AED) system being developed at Massachusetts Institute of Technology. AED is powerful and useful for building the procedures that handle the data beads. In particular, a great deal of flexibility was acquired because it was possible to change the structure of the data beads and the procedures that manipulate them, without the necessity of major revisions to the remaining data structure and associated procedures. Extract: 3 functions of system flow
Slide I shows the three major functions of the system flow. The first
function is to describe and store a description of the 3-dimensional part. A part description language, including only planes and cylinders, was sufficient for experimenting with a variety of parts. The second function of the system flow is to retrieve the stored data for calculation purposes. The calculation procedures include processing the 3-dimensional description of the part for the
desired view, computing view oriented data (profile, projection, cross section, hidden line), and presenting the data in the form required by the display device.
The third function of the system flow is to manipulate the information displayed on the screen. Some of the operations (such as moving information on the aisplay screen) make the system flow so that only control and output routines are involved. Other operations (such as computing new views) make the system flow so that it must retrieve the 3-D model and activate calculation procedures. Still other operations (such as changing the description of the part) make the system flow so the language input subroutines are activated.
The data structure concerns itself with 3-dimensional geometric information and establishes a hierarchy of information for handling surfaces, lines, and points. The data structure is so organized that it is possible to readily retrieve the information after it is stored in the computer. A question that might be asked of a system is: "What is the name of the geometry displayed on the CRT and I am pointing at with the light pen?" Another question might be, "Where is the geometry whose name I am typing on the keyboard?" In either case, a data structure must be so organized that the information can be quickly accessed and retrieved.
in [ACM/IEEE] Proceedings of the SHARE Design Automation Project Annual ACM IEEE Design Automation Conference 1965 view details
in Proceedings of the 22nd national ACM conference 1967, Washington, D.C. view details
AED (Automated Engineering Design) A generalized language, system, and set of concepts; includes AED Jr., AED 0, AED I. Based on ALGOL and an algorithmic theory of language. Provides techniques for building processors for new languages
in Computers & Automation 16(6) June 1967 view details
Doug Ross, MIT - Electronic Systems Lab
When I saw the title of this panel discussion, "Is There a Best Programming Language for Design Automation?", I thought that this would be the shortest remark I ever had to make - one word, AED, and then I got to thinking about it and noticed that wasn't really keeping to the subject of the panel~ so I had to double the length of the paper and say, "Yes, AED."
I really don't feel terribly controversial yet this afternoon~ so lwould like to be very brief and merely try to put a slight twist~ or maybe an elaboration on the title of the panel, because I think it is ambiguous as it' s stated and we should spend some time trying to remove this ambiguity.
Mainly, are we talking about a programming language for making a design system or a programming language for a designer to use in doing design. It seems to me that the key point is that it must be that we are to be talking about the design system building language because I've been listening to various of the talks given here and also ones given over the past several years other places and I think that the contention that we have had from the beginning of our interest is computer-aid design, which goes back quite a ways, is borne out-mainly, that what is needed as far as the users of design systems are concerned is not a single best language, but a very large number of specialized languages, so that each kind of user can use his own "shop talk jargon," needknownothing about programming preferably, etc. , etc. So, I think that we must be talking not about languages for the designer to use, but, rather~ languages for building design systems.
Then, too, if we now are going to be talking about languages for building design systems, Ithinkthat there, too, is another layer of ambiguity-- potential ambiguity--or a layer of things that need to be clarified. Mainly, are we talking about just a language, or are we talking about more than just the language and here again, my contention is that it must be that we talk about more than just the language, mainly a language embedded in a system or systematic way of using the language. In other words, what you write on paper itself is not the important thing, it is how you go about using the language to create a design system.
A couple of years ago--I guess it is almost two years ago now--somebody used a term and I wish I could remember it because I would like very much to acknowledge it. They used a term in connection with programming languages which struck me as being very important and, in fact, is the place where I thought this afternoon' s panel discussion really should focus, and that was with respect to a programming language there is a culture that goes along with the use of that language and I think that this is the real key point--is the culture the whole method of using the language of creating systems, and so forth. This is the central point if we are to make much headway in making design systems without everybody going broke in the process and, also, incidentally, hopefully meeting some software timing schedules.
I' d like to just sort of stop at this point by saying that this view has been behind all of our activities in the computer-aid design project at MIT since we started in 1959. We said in those days, the way we put it was we couldn't possibly learn as much about design as all of the various people in industry,
in Proceedings of the 4th Annual ACM IEEE Design Automation Conference archive view details
in Bobrow, D. G. (ed) "Symbol Manipulation Languages and Techniques", Proceedings of the IFIP Working Conference on Symbol Manipulation Languages. North-Holland Publishing Co., Amsterdam, 1968 view details
in Bobrow, D. G. (ed) "Symbol Manipulation Languages and Techniques", Proceedings of the IFIP Working Conference on Symbol Manipulation Languages. North-Holland Publishing Co., Amsterdam, 1968 view details
PREFACE
DYNAMO is a computer program for building and running "continuous" simulation models (models which can be described by a set of differential equations). It was developed by the Industrial Dynamics Group at the Massachusetts Institute of Technology for simulating dynamic feedback models of business, economic, and social systems, but nothing in its design precludes its use for any continuous system.
DYNAMO has been designed for the person who is problem-oriented rather than computer-oriented. It makes available easy-to-use computing facilities so that you can focus your attention on building a useful model, undistracted by complex computer requirements.
DYNAMO'S requirements with respect to the order in which statements appear are trivial, contributing greatly to the ease of using it. DYNAMO figures out which variables must be computed first, and will even initialize many variables for you.
DYNAMO thoroughly checks models for errors before trying to run them. Run-time errors as well as compiler errors are reported in English rather than by number, so that most of the time you will not need the manual to understand an error message. You will never be left with just a system "dump" to describe an error.
The mechanics of running DYNAMO are very simple. Both tabulated and plotted output can be specified easily. Even the results of different runs can be compared directly (displayed on a single graph or tabulated listing). This is especially useful for evaluating a policy or parameter change.
The DYNAMO language includes time subscripts that enable you to comprehend easily how the calculations are made. These subscripts describe a very simple integration scheme (rectangular or Euler's method), which is also very efficient when great accuracy is not required. As you gain confidence that DYNAMO isn't doing anything you don't know about, you will be free to concentrate on designing your model and ignore the computational details. (For the mathematically-minded, DYNAMO IV offers the option of using a third-order Runge-Kutta integration method.)
Experienced users should note that DYNAMO offers two facilities to simplify the construction of large models. User-defined functions, or macros, can be written in standard DYNAMO statements with DYNAMO II, III, and IV. (FORTRAN, or other language, programs can be linked to DYNAMO models via the External Function Facility.) DYNAMO III and IV also offer the use of arrays, to simplify the modeling of repeated structures.
Extract: BRIEF HISTORY OF DYNAMO
BRIEF HISTORY OF DYNAMO
The history of DYNAMO begins with a program called SIMPLE (Simulation of Industrial Management Problems with Lots of Equations), written by Richard K. Bennett in the spring of 1958 for the IBM 704 Computer. SIMPLE contained most of the basic features of DYNAMO, including the plotting routine (written by Edward B. Roberts); but the model specifications had to be stated in a rather primitive form, and very few checks were performed on these specifications. These shortcomings were corrected by DYNAMO (DYNAmic MOdels), written by Phyllis Fox (Mrs. George Sternlieb) and Alexander L. Pugh, III, and completed in the spring of 1959. Mr. Roberts
modified and improved the plotting routine, and Grace Duren and David J. Howard assisted with other phases of the program.
The program was rewritten the following summer by the same team. Following this effort the maintenance of DYNAMO became the responsibility of Mr. Pugh. When M.I.T. replaced the 704 with the 709, DYNAMO was converted to run on the new machine. In 1962, Jay W. Forrester of M.I.T. suggested a relaxation of the requirements on initial values, which was implemented. When C.T.S.S. (Compatible Time Sharing System) became generally available, DYNAMO was modified to operate under it. This facility made it possible to create, debug, and run a model in a matter of hours, the output returning directly back to the console.
In 1965 it was decided to rewrite DYNAMO. Although the input language gave the appearance of actual equations, DYNAMO I was basically a macro expansion program. Simple algorithms for algebraic translation were now well understood and could be utilized in DYNAMO II to relax the restrictions on equation formulation. Furthermore, higher-level languages had advanced to the point where they could be used as source languages to simplify the chore of rewriting the compiler. Finally, the third generation of hardware was rapidly replacing the equipment for which DYNAMO was written, and some sort of rewrite would be required before long.
AED (Algol Extended for Design) was chosen as the source language because it appeared to be one of the two or three languages then in existence having the power to do the job and because both the language and its authors were available at M.I.T. The choice proved to be wise. AED did have the necessary power; only about 2 percent of the compiler is written in assembly language. The availability of AED on both machines greatly simplified the conversion from the 7094 (CTSS) to the. S/360. (Donald A. Belfer assisted in this conversion.)
DYNAMO II was designed to accept models written for DYNAMO I with few changes. Most models will run with no changes or perhaps one, although models that contain boxcars now require DYNAMO III. The meaning of the asterisk was changed to multiplication as in most algebraic languages. (Back-to-back parentheses continue to imply multiplication.) Error checking was extensive in DYNAMO I; error recovery has been the object in DYNAMO II. Only a few errors preclude the running of a model.
In response to the demand for DYNAMO on computers other than the IBM 360-370 computers, Richard Wright and Mr. Pugh of the consulting firm of Pugh-Roberts Associates, Inc., developed a FORTRAN-based version in 1971. DYNAMO II/F translates a model into FORTRAN and supports its execution with the standard DYNAMO functions and output routines. As this version is entirely written in FORTRAN, the only hardware requirement for its installation is a computer that supports a version of FORTRAN relatively close to the full American National Standard.
Interactive (time sharing) versions of DYNAMO have been popular since the advent of the first CTSS version. DYNAMO II was first checked out as an interactive version, and the first S/360 DYNAMO operated under CP67/CMS. In 1971, the interactive version was converted to the RAX operating system by Pugh-Roberts Associates and Boston University, and in 1972 this version was tuned to the TSO system. An interactive version of DYNAMO II/F was developed in 1972 by Mr. Wright.
An interactive version of DYNAMO suggests the possibility of interaction during the simulation. The user might examine the state of the system and decide what action he feels is appropriate. Such a version of DYNAMO has been developed by Mr. Pugh and is referred to as Gaming DYNAMO, as gaming is one of the obvious uses for such a system. A game is constructed from all the usual DYNAMO equation types plus one additional type ? Decision. Decisions are those variables that can be changed during interaction with the game. The current Gaming DYNAMO was developed by D. Ross Hunter of Pugh-Roberts Associates, Inc. as an extension to DYNAMO/F.
In response to the growing number of models containing sectors repeated several times to represent reality in a more disaggregate manner, an array-handling capability was added to DYNAMO by William A. Shaffer and Mr. Pugh of Pugh-Roberts Associates. This version, designated DYNAMO III, was designed to be consistent with FORTRAN'S and implemented within the framework of DYNAMO II/F. Through the vehicle of implicit DO loops, equations involving arrays can occur in any order, retaining DYNAMO'S minimal requirements on the order of model statements.
The growing size of DYNAMO III models, in conjunction with the size limitation of IBM's FORTRANs, led Mr. Pugh to develop during 1976 a DYNAMO III compiler, specifically for IBM computers, that will compile huge models rapidly. This version is referred to as DYNAMO HI/370. Between 1976 and 1983, Mr. Pugh made numerous improvements to DYNAMO HI/370, most notably, the addition of the PRESERVE and RESUME feature. In 1983, Mr. Hunter and Todd Sjoblom of Pugh-Roberts Associates, Inc. developed DYNAMO III/F+, to incorporate as many of the DYNAMO HI/370 features as possible in a FORTRAN-based DYNAMO.
To support schools and colleges that were teaching System Dynamics, but only had access to mini-computers, Dr. Shaffer developed Mini-DYNAMO for Pugh-Roberts Associates, Inc. in 1976. Unlike earlier DYNAMOs, Mini-DYNAMO interpreted rather than executed the code it generated so that runtime errors, such as division by zero, could be reported in a manner the user could easily understand. Recently, microcomputers have become readily affordable both by schools and by individuals. To make DYNAMO available on such machines, Jay P. Werb of Pugh-Roberts Associates, Inc., converted Mini-DYNAMO to run on the Apple II computer in 1981. (While the language of Mini-and Micro-DYNAMO are upward compatible with DYNAMO II, III, and IV, the reference manuals for those programs are the Mini-
DYNAMO user's Guide, William A. Shaffer, 1977, published by Pugh-Roberts Associates, Inc., and User Guide and Reference Manual for Micro-DYNAMO, Pugh-Roberts Associates, Inc., 1982, published by Addison-Wesley.)
Documenting any computer program has always been tedious. To simplify the mechanical chore of merging variable definitions following the equations where they are used, Mr. Pugh wrote the Documentor in 1960. Once DYNAMO had been converted to the S/360 he rewrote it in AED. In 1976, Mr. Hunter rewrote it again and improved it. This time it was written in FORTRAN so that it could be run on practically any machine supporting DYNAMO. Mr. Hunter also wrote chapter 7 of this book, the DOCUMENTOR/F user's Manual.
The early development of DYNAMO was supported financially by the Ford Foundation, International Business Machines, Project MAC at the Massachusetts Institute of Technology, and Humble Oil and Refining Co. Extract: BRIEF HISTORY OF DYNAMO
BRIEF HISTORY OF DYNAMO
The history of DYNAMO begins with a program called SIMPLE (Simulation of Industrial Management Problems with Lots of Equations), written by Richard K. Bennett in the spring of 1958 for the IBM 704 Computer. SIMPLE contained most of the basic features of DYNAMO, including the plotting routine (written by Edward B. Roberts); but the model specifications had to be stated in a rather primitive form, and very few checks were performed on these specifications. These shortcomings were corrected by DYNAMO (DYNAmic MOdels), written by Phyllis Fox (Mrs. George Sternlieb) and Alexander L. Pugh, III, and completed in the spring of 1959. Mr. Roberts
modified and improved the plotting routine, and Grace Duren and David J. Howard assisted with other phases of the program.
The program was rewritten the following summer by the same team. Following this effort the maintenance of DYNAMO became the responsibility of Mr. Pugh. When M.I.T. replaced the 704 with the 709, DYNAMO was converted to run on the new machine. In 1962, Jay W. Forrester of M.I.T. suggested a relaxation of the requirements on initial values, which was implemented. When C.T.S.S. (Compatible Time Sharing System) became generally available, DYNAMO was modified to operate under it. This facility made it possible to create, debug, and run a model in a matter of hours, the output returning directly back to the console.
In 1965 it was decided to rewrite DYNAMO. Although the input language gave the appearance of actual equations, DYNAMO I was basically a macro expansion program. Simple algorithms for algebraic translation were now well understood and could be utilized in DYNAMO II to relax the restrictions on equation formulation. Furthermore, higher-level languages had advanced to the point where they could be used as source languages to simplify the chore of rewriting the compiler. Finally, the third generation of hardware was rapidly replacing the equipment for which DYNAMO was written, and some sort of rewrite would be required before long.
AED (Algol Extended for Design) was chosen as the source language because it appeared to be one of the two or three languages then in existence having the power to do the job and because both the language and its authors were available at M.I.T. The choice proved to be wise. AED did have the necessary power; only about 2 percent of the compiler is written in assembly language. The availability of AED on both machines greatly simplified the conversion from the 7094 (CTSS) to the. S/360. (Donald A. Belfer assisted in this conversion.)
DYNAMO II was designed to accept models written for DYNAMO I with few changes. Most models will run with no changes or perhaps one, although models that contain boxcars now require DYNAMO III. The meaning of the asterisk was changed to multiplication as in most algebraic languages. (Back-to-back parentheses continue to imply multiplication.) Error checking was extensive in DYNAMO I; error recovery has been the object in DYNAMO II. Only a few errors preclude the running of a model.
In response to the demand for DYNAMO on computers other than the IBM 360-370 computers, Richard Wright and Mr. Pugh of the consulting firm of Pugh-Roberts Associates, Inc., developed a FORTRAN-based version in 1971. DYNAMO II/F translates a model into FORTRAN and supports its execution with the standard DYNAMO functions and output routines. As this version is entirely written in FORTRAN, the only hardware requirement for its installation is a computer that supports a version of FORTRAN relatively close to the full American National Standard.
Interactive (time sharing) versions of DYNAMO have been popular since the advent of the first CTSS version. DYNAMO II was first checked out as an interactive version, and the first S/360 DYNAMO operated under CP67/CMS. In 1971, the interactive version was converted to the RAX operating system by Pugh-Roberts Associates and Boston University, and in 1972 this version was tuned to the TSO system. An interactive version of DYNAMO II/F was developed in 1972 by Mr. Wright.
An interactive version of DYNAMO suggests the possibility of interaction during the simulation. The user might examine the state of the system and decide what action he feels is appropriate. Such a version of DYNAMO has been developed by Mr. Pugh and is referred to as Gaming DYNAMO, as gaming is one of the obvious uses for such a system. A game is constructed from all the usual DYNAMO equation types plus one additional type ? Decision. Decisions are those variables that can be changed during interaction with the game. The current Gaming DYNAMO was developed by D. Ross Hunter of Pugh-Roberts Associates, Inc. as an extension to DYNAMO/F.
In response to the growing number of models containing sectors repeated several times to represent reality in a more disaggregate manner, an array-handling capability was added to DYNAMO by William A. Shaffer and Mr. Pugh of Pugh-Roberts Associates. This version, designated DYNAMO III, was designed to be consistent with FORTRAN'S and implemented within the framework of DYNAMO II/F. Through the vehicle of implicit DO loops, equations involving arrays can occur in any order, retaining DYNAMO'S minimal requirements on the order of model statements.
The growing size of DYNAMO III models, in conjunction with the size limitation of IBM's FORTRANs, led Mr. Pugh to develop during 1976 a DYNAMO III compiler, specifically for IBM computers, that will compile huge models rapidly. This version is referred to as DYNAMO HI/370. Between 1976 and 1983, Mr. Pugh made numerous improvements to DYNAMO HI/370, most notably, the addition of the PRESERVE and RESUME feature. In 1983, Mr. Hunter and Todd Sjoblom of Pugh-Roberts Associates, Inc. developed DYNAMO III/F+, to incorporate as many of the DYNAMO HI/370 features as possible in a FORTRAN-based DYNAMO.
To support schools and colleges that were teaching System Dynamics, but only had access to mini-computers, Dr. Shaffer developed Mini-DYNAMO for Pugh-Roberts Associates, Inc. in 1976. Unlike earlier DYNAMOs, Mini-DYNAMO interpreted rather than executed the code it generated so that runtime errors, such as division by zero, could be reported in a manner the user could easily understand. Recently, microcomputers have become readily affordable both by schools and by individuals. To make DYNAMO available on such machines, Jay P. Werb of Pugh-Roberts Associates, Inc., converted Mini-DYNAMO to run on the Apple II computer in 1981. (While the language of Mini-and Micro-DYNAMO are upward compatible with DYNAMO II, III, and IV, the reference manuals for those programs are the Mini-
DYNAMO user's Guide, William A. Shaffer, 1977, published by Pugh-Roberts Associates, Inc., and User Guide and Reference Manual for Micro-DYNAMO, Pugh-Roberts Associates, Inc., 1982, published by Addison-Wesley.)
Documenting any computer program has always been tedious. To simplify the mechanical chore of merging variable definitions following the equations where they are used, Mr. Pugh wrote the Documentor in 1960. Once DYNAMO had been converted to the S/360 he rewrote it in AED. In 1976, Mr. Hunter rewrote it again and improved it. This time it was written in FORTRAN so that it could be run on practically any machine supporting DYNAMO. Mr. Hunter also wrote chapter 7 of this book, the DOCUMENTOR/F user's Manual.
The early development of DYNAMO was supported financially by the Ford Foundation, International Business Machines, Project MAC at the Massachusetts Institute of Technology, and Humble Oil and Refining Co.
in Bobrow, D. G. (ed) "Symbol Manipulation Languages and Techniques", Proceedings of the IFIP Working Conference on Symbol Manipulation Languages. North-Holland Publishing Co., Amsterdam, 1968 view details
in Computers & Automation 21(6B), 30 Aug 1972 view details
in Computers & Automation 21(6B), 30 Aug 1972 view details
AED (Automated Engineering Design)
AED is a powerful systems implementation language with many features similar to those in PL/I. Many features are handled by procedure calls to a library. FORTRAN programs can be used as part of AED programs. Most of the compiler is written in AED. The major use is for systems implementation but it can also be used for large applications in business and engineering.
Implemented on: Several large computers with several cross-compilers to small machines.
Ref: Ross D. T., "The Automated Engineering Design (AED) Approach to Generalized Computer-Aided Design," Proc. ACM 22nd Nat'l Conf (1967); Introduction to AED Programming, SofTech, 460 Totten Pond Rd., Waltham, Mass. 02154 (Nov. 1973).
Contact: SofTech.
Application Area: Multipurpose.
in ACM Computing Reviews 15(04) April 1974 view details
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
in ACM Computing Reviews 15(04) April 1974 view details
in ACM Computing Reviews 15(04) April 1974 view details
AED is a powerful systems implementation language with many features similar to those in PL/I. Many features are handled by procedure calls to a library. FORTRAN programs can be used as part of AED programs. Most of the compiler is written in AED. The major use is for systems implementation but it can also be used for large applications in business and engineering.
in SIGPLAN Notices 13(11) Nov 1978 view details
in SIGPLAN Notices 13(11) Nov 1978 view details