DISPLAYTRAN(ID:4978/dis008)
Interactive graphically oriented language for querying
Based on QUIKTRAN, developed for the Naval Weapons Lab by IBM to enable interactive graphics programming
D. Green Naval Weapons Lab. Dahlgren, Va.
R. Cornish, IBM Corp. Washington, D.C.
Places
Related languages
| ALPINE | => | DISPLAYTRAN | Influence | |
| MIDAS | => | DISPLAYTRAN | Influence | |
| MIMIC | => | DISPLAYTRAN | Influence | |
| QUIKTRAN | => | DISPLAYTRAN | Augmentation of |
References:
in Proc. IFIP TC2 Working Conf. on Formal Language Description Languages for Computer Languages, North-Holland, Amsterdam, 1966 view details
Extract: Introduction
Introduction
In the first part of this presentation, I would like to spend a few minutes on background information on NWL and on the goals and history of the project of which DISPLAYTRAN is a part so as to put the work which will be described in its proper perspective. I will also describe briefly several other parts of this project which are of interest. The second part of the presentation will discuss DISPLAYTRAN at some length.
NWL is a laboratory working under the direction of the Bureau of Naval Weapons. It has as its function research and development directed toward weapons and weapons systems as well as testing and evaluation of these. This work led quite early to a requirement for high speed, high precision digital computers, especially for work involving trajectory computations. As a result, the Aiken MARK II relay calculator was installed in 1946. This was followed by the MARK III in 1950, and the NORC in 1955. Currently the major computing facility is the STRETCH. A Stromberg Carlson Charactron tube printer-plotter was installed on the NORC in 1959 and still serves on its principal output unit. A similar device is available off-line to STRETCH users and is extensively used for both printing and plotting. Besides the large digital facility, there also exists at NWL a small analog computational facility, which is used in a variety of simulation problems arising in weapons development. This is currently being expanded.
Besides its continuing interest in having the most up-to-date computing equipment available for use by its scientists and engineers, NWL has, of course, long been interested in those developments which would allow this hardware to be more effectively used by the programmers, scientists and engineers of the laboratory. While currently most programming is handled on a closed shop basis, by a staff of about 65 professional programmers, it was recognized several years ago that studies such as those at project MAC indicated both the potential usefulness and practicability of direct access and reactive or conversational computing.
A project was therefore set up in the Programming Systems Branch of the Programming Division to investigate and study these developments and to see how they could be exploited at NWL to improve the productivity of scientific manpower. It was early decided to in particular explore the utility of display or graphical devices. To further this work, it was decided to obtain a limited number of graphical terminals. A 360/40 system was acquired for the purpose of driving these terminals and also to replace one of the two 1401's then installed in the laboratory for peripheral processing. The configuration is as shown in this slide. (Fig. 1). You will note that besides the two user terminals, there are two terminals to be used respectively for preparing STRETCH system input tapes and printing STRETCH system output tapes. After the acquisition of this system, the Data Processing Division of IBM expressed an interest in joining with NWL in this project and have since January 1965 actively joined with NWL in the work undertaken as part of it.
In pursuing this project the four areas in which NWL feels particularly interested are summarized on this slide. (Fig. 2). Currently most emphasis is being placed on the first two areas with lesser amounts on the latter two. Extract: Utilization of Existing Systems
Utilization of Existing Systems
So that we might gain practical experience as soon as possible we decided to utilize several existing systems - principally the QUIKTRAN and ALPINE systems among the conversational systems, and the MIDAS simulation language (implemented in a batch mode on STRETCH) to explore the interesting area of digital analog simulation languages as a means for aiding in the solution of problems typically handled on analog or hybrid computers. This language has found acceptance with our engineering staff.
In employing QUIKTRAN, our principal goals were to evaluate the utility of conversational FORTRAN to the scientists, engineers and programmers of the laboratory, and to study the typewriter type of terminal. We permitted, a variety of people from the scientific, engineering, and programming staff to use the system under controlled but realistic conditions. While I do not intend to go into the results of our study here, they were quite interesting and have had significant influence on our current course of action.
The ALPINE system was used to gain early experience with a graphical input-output terminal. The problem we chose to implement was a simplified version of one of long standing interest to NWL, the determination of drag function for free fall weapons. The experiment showed the feasibility of the approach for solving this type of problem, but more important here showed the power of the FORTRAN oriented graphical language available on this system. This language, along with our experience with graphical output devices, forms the basis for the user oriented graphical language embedded in the DISPLAYTRAN system.
With this background established, I would like to spend the remainder of the time in describing three user oriented systems that are being developed as parts of this project. We call them AAPl, OLDAS, and DISPLAYTRAN. Each attempts to adapt the digital computer to the user for a particular class of problems using the 2250 as a terminal.
Extract: Summary
SUMMARY
To summarize, let us briefly review the experiment and results. We set out to devise economically feasible means of increasing the throughput of the scientist at NWL through the use of conversational computing and graphics. To achieve this goal, we elected to first experiment with available systems to direct or design of suitable tool for experimentation that could be developed for the S/360. Our experiments with QUIKTRAN were encouraging, and influenced the development of AAPl as a local offering - the QUIKTRAN system is still operational. Our experiments with ALPINE Graphic FORTRAN were encouraging also, and in conjunction with QUIKTRAN results, led directly to the development of OLDAS and DISPLAYTRAN for further experimentation in an operational environment. We believe that the experiments have been successful, both in demonstrating that the general techniques are useful and in clearly identifying a useful product for continued, productive experimentation.
Extract: Prognosis
PROGNOSIS
Using the DISPLAYTRAN system, programmers at NWL will now be able to develop graphic application programs in a conversational mode. Scientists at NWL will be able to experiment with these programs in a conversational mode. Both will be made practical by a time sharing technique. This conversational, graphic link between scientific personnel and the computer will, we believe, truly increase their throughput. It brings the computer closer to the human creative process. Extract: Quiktran and Displaytran
Introduction
Our QUIKTRAN experiments gave the expected results - that conversational computing is a very useful tool for the scientist, but some extensions were implied, particularly with respect to large programs. Our experiment with the ALPINE Graphic FORTRAN System also led us to an expected conclusion - that conversational graphics is a good technique for solving some problems, but impractical on a dedicated machine. The obvious product of this line of reasoning is a conversational Graphic FORTRAN System for continued experimentation with techniques for increasing the throughput of scientific personnel. Our intermediate goal, DISPLAYTRAN, is this conversational Graphic FORTRAN System, and will be the subject of the remainder of this paper.
DISPLAYTRAN, now under development for the IBM S/360 Mod. 40, will be shared in a conversational mode from two display oriented terminals. Consisting essentially of FORTRAN IV with graphic subroutines, the PROGRAM language will be controlled through the use of a COMMAND language built around the same graphic terminals.
The programmer, who will work at one of these terminals, will be able to develop graphic applications in a conversational mode. While accepting program statements either singly or batched, the system verifies each element of input. After data verification, the new program can be executed individually or in conjunction with any number of debugging aids.
The scientist, who will also work at a graphic terminal, will be able to execute and converse with any completed application program.
Extract: Quiktran and Displaytran externalities
Externals
The external specification of the system consists of a description of the HARDWARE CONFIGURATION, the PROGRAM language and the COMMAND language.
Based on an IBM S/360 Mod. 40 with 2 2311 disk drives and 3 2400 tape drives, the system supports 2 conversational terminals. Each conversational terminal has one 2250 display console, one 1092 functional keyboard and a 1053 printer. Each display console is equipped with light pen, character generator, vector generator, keyboard and buffer. A detailed configuration is shown in Fig. i.
The PROGRAM language, which is essentially a FORTRAN IV interpreter with a display subroutine capability, is used by the programmer to code all programs.
Application coding in DISPLAYTRAN, with the exception of a few restrictions, will be identical to coding in FORTRAN IV where the display subroutines are activated by SUBROUTINE CALL statements. DISPLA¥ -TRAN statements are entered via the 2250 keyboard with the help of system COMMANDS. While it runs, any DISPLAYTRAN application program can input/output graphic or alphanumeric data via the conversational terminal, in addition to using the normal system input/output devices.
Directing the overall system, the COMMAND language is activated through the 1092 functional keyboard virtually eliminating interference with active DISPLAYTRAN programs. Included among the system functions thus activated are application program initiation, program development and debugging aids, sign on and sign off procedures. All communication with the system, excluding application programs, is accomplished via the COMMAND LANGUAGE.
Because interpretive systems are inherently slow, DISPLAYTRAN has the facility for running restricted machine language SUBROUTINES. The facility is designed for time consuming portions of debugged, repetitive applications while excluding generalized machine language programs.
Extract: DISPLAYTRAN programming language
Program Language
The DISPLAYTRAN language, used for coding the application programs, is basically FORTRAN IV with graphic subroutines. The graphic subroutines will be similar to those found in the S/360 GFS. From an external point of view, the DISPLAYTRAN language is not unlike GFS in a shared mode. I will not belabor the graphic subroutines, as they were presented in another paper.
During run mode, while an application program is in command of the system, the application program drives the graphic devices. Only the bottom line of the scope will be reserved for system messages.
As an example of a conversational graphic application, let's take another look at our ALPINE experiment.
The scientists goal here is to develop an empirical drag curve by-successive approximations. This is accomplished by comparing a computed trajectory, which is a function of his approximated drag curve, against a trajectory collected from live experiments, until a match is indicated. The match is depicted by a reference curve showing the differences between the trajectories as a function of time. The scientist is able to approximate the required changes by observing the shape of the reference curve. When the reference curve is straight, indicating a constant difference, the experiment is complete.
Initial conditions for the comparison and computed trajectory are selected using the display shown in Fig. 20. The differences between the computed and live trajectories are displayed as a function of time - as in Fig. 21. Upon examination of this curve, the scientist is able to project what is wrong with his approximated drag curve. He then displays his drag curve, as shown in Fig. 22, which represents his approximation, corrects it with his light pen, and recomputes the difference curve. Successive iteration will result in the good approximation indicated by Fig. 23, after which he saves the latest drag curve approximation.
in [ACM/IEEE] Proceedings of the SHARE Design Automation Project Annual ACM IEEE Design Automation Conference 1965 view details
Programming implies anticipating all conditions that may arise in the course of solving a problem. Unfortunately, not all problem solving lends itself to this tidy approach. In many cases, each successive step can only be planned after the succeeding step has been completed. Thus, effective use of graphics devices for interactive problem solving requires some means for requesting that a data processing system perform functions not anticipated at the beginning of the problem-solving process. This fundamental problem has been attacked in various ways. For example, one system provides for a library of previously compiled computation modules that can be called by the display console operator as needed. However, that approach assumes that the needed computation modules exist.
The system discussed here interprets and executes FORTRAN statements as they are entered from the display console. For example, if a console operator, after seeing a display of a geometric figure on the screen, decides that he would like to perform an unanticipated computation, he can do so without a separate compilation run. He simply enters FORTRAN statements at the display console, which are interpreted in real time and then executed.
Interpretive FORTRAN execution also ameliorates the problem of debugging for graphics programmers. Syntax errors are revealed as soon as the system attempts to interpret each statement. Also, errors in logic can be corrected more easily because the console operator can stop execution at any point he desires. These facilities are provided for the graphics as well as the computational portions of application programs.
The system discussed here is called DISPLAYTRAN, which takes its name by analogy from QUIKTRAN. Like QUIKTRAN, DISPLAYTRAN provides interpretive FORTRAN execution for interactive problem solving. Many of the capabilities of DISPLAYTRAN are useful for graphics applications, although the system is not designed exclusively for graphics jobs. Graphics and other jobs can be entered directly from the console, and batch processing can be done concurrently in a background partition of main storage. The system provides time slicing for jobs done at the display console. Generalpurpose graphics subroutines are supplied for FORTRAN programmers, and can be called from a program being constructed at the display console.
DISPLAYTRAN is one result of studies undertaken jointly by the International Business Machines Corporation and the U. S. Naval Weapons Laboratory.
The first part of the following discussion deals with the overall relationships among the display terminal, the computer configuration, and the operating system. The remainder of the paper emphasizes the languages provided, which include a command language, the FORTRAN IV subset, and the graphics language. Also, the manner in which the console operator can call and execute previously compiled subprograms is discussed briefly. Extract: Summary comment
Summary comment
Begun as an exploratory development in 1964, DISPLAYTRAN has proved itself in operation, and it is continuing to be improved especially in the areas of performance and capability. Being added is the preloading of symbolic programs from a card reader.
For the Naval Weapons Laboratory, which is mainly FORTRAN IV-oriented, the system provides means for efficient FORTRAN program writing, debugging, and maintaining. Graphic displays aid programmers, engineers, and scientists according to their needs.
DISPLAYTRAN is a nondedicated system and is compatible with It is possible to modify DISPLAYTRAN to become a production tool instead of an experimental facility. Additional capabilities could be incorporated as well as means for supporting other types of terminals that might be needed in a time-sharing environment.
The fact that DISPLAYTRAN is capable of producing useful work makes it desirable to further exploit this system.
in IBM Systems Journal, 7(3 and 4) 1968 view details
in Computers & Automation 21(6B), 30 Aug 1972 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 Computers & Automation 21(6B), 30 Aug 1972 view details
Resources
- DISPLAYTRAN program and results from Green 1966
- DISPLAYTRAN program dialog from Green 1966
- DISPLAYTRAN program output from Green 1966
- DISPLAYTRAN screen from Green 1966
- DISPLAYTRAN screen from Green 1966
- DISPLAYTRAN screen from Green 1966
- DISPLAYTRAN screen from Green 1966
