QUIKTRAN(ID:461/qui011)
FORTRAN-like, interactive with debugging facilities
FORTRAN-like, interactive with debugging facilities.
Related languages
| Basic FORTRAN | => | QUIKTRAN | Augmentation of | |
| QUIKTRAN | => | DISPLAYTRAN | Augmentation of |
References:
in [AFIPS JCC 25] Proceedings of the 1964 Spring Joint Computer Conference SJCC 1964 view details
in [AFIPS JCC 25] Proceedings of the 1964 Spring Joint Computer Conference SJCC 1964 view details
in Datamation 11(2) Feb 1965 view details
in Datamation 11(2) Feb 1965 view details
in Datamation 11(2) Feb 1965 view details
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: 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.
in [ACM/IEEE] Proceedings of the SHARE Design Automation Project Annual ACM IEEE Design Automation Conference 1965 view details
General philosophy
AMTRAN is a multi-level language. It can be used by the Systems programmer at the level of bit manipulation or by the applied mathematician with no prior knowledge of computing, or by practitioners at any intermediate level. The system can be used in an on-line, conversational mode or in an off-line, batch-processing mode or in any combination of the two. The keyboards, cathode ray scopes and typewriters provide low-cost adjuncts to the usual card, printer, tape, and plotter attachments.
Three objectives have been of primary importance in the development of the AMTRAN system.
First, a scientist or an engineer with no background in computer techniques should be able to solve relatively straightforward mathematical problems with little or no instruction in the use of the AMTRAN system. For this purpose, the system has standard "convenience" operators in the language of classical mathematics, such as F, d/dx mini-max, etc., which suffice for a large fraction of the problems commonly encountered by the scientist or engineer.
Also, the AMTRAN language has been considerably streamlined to permit the user to "converse" with the computer in the natural language of mathematics. For example, the system provides automatic array arithmetic, automatic dynamic dimensioning of arrays, no declaration of variables, automatic assignment of working storage, implied multiplication, natural-English input and output, "picture" formatting, and other adjuncts to natural mathematics.
Second, the programmer and the more experienced user'should be provided with the capability to construct their own programs and operators at the keyboard so that they can handle problems for which the standard set of operators is inadequate and so that they can take advantage of the extremely short turnaround times which are characteristic of conversation-mode programming. This requirement has been met by including algol 60 programming capabilities with certain programming extensions?e.g., high- level logical and transfer instructions, extensive list-processing and symbol manipulation capabilities, graphical input and output instructions, etc. Perhaps the most important feature is a simplified procedure-and-operator generation arrangement which permits the construction from the keyboard of general-purpose "super-instructions." These can then be stored in a disc-file library. This means that the programmer is not restricted to 30 to 40 basic FORTRAN-level instructions, but can, in effect, draw upon a repertoire of hundreds or thousands of general-purpose mathematical and logical procedures as building blocks for his programs.
Third, the system must be economically competitive with batch-processing systems in speed and storage. This requirement will be met through an incremental compiler. Extract: Conclusion
Conclusion
An effort has been made in the development of AMTRAN to develop a broad-based programming system which spans the spectrum from a streamlined machine language for the professional programmer to the highest level mathematical operations (for the scientist or engineer).
In addition to the writing of an incremental compiler, future plans call for effort in the areas of symbol manipulation, automatic numerical analysis, and the introduction of new simplified basic programming operations. It is hoped that these improvements, particularly in the symbol manipulation area, will improve the programming checkout and debugging rates beyond their present values. Turnaround times are presently running 5% to 10% of the batch processing rates.
An interesting result of our demonstrations has been the response of scientists and engineers to the system. The reaction is invariably "Where can I get one of these?". There is no doubt that a market exists for a conversational-mode computer system which speaks the natural language of. mathematics as nearly as possible, and which relieves the user of all those programming and analytical bookkeeping operations which can be prescribed in "cook-book" terms. Of course, incorporating the procedures of classical and numerical analysis into an on-line computer system is a formidable task. Nevertheless, we hope AMTRAN will provide a first step toward everyday use of an automatic mathematical system for on-line computation.
Extract: Other conversational mode systems
Other conversational mode systems
The basic inspiration for AMTRAN was the Thompson-Ramo-Wooldridge on-line computer system originated by G. J. Culler and B. D. Fried and later extended by Culler at the Univ. of California (Santa Barbara). The Culler-Fried system utilizes a 5-inch Tektronix storage scope, a typewriter keyboard, and another typewriter keyboard with specially-labeled operator keys. The system possesses the ability to handle complex numbers, two-dimensional arrays, vectors and matrices. It is designed to permit the console programming of operators or instructions and it also provides array arithmetic. It is very fast in execution. Although there are similarities between AMTRAN and the Culler-Fried systems, there are also sizable differences.
Another early conversational mode system consists of the RAND Corporations highly-polished JOSS system, which has formed the basis for the Burroughs INTERP system and the SDS CAL language. Four more recent conversational mode languages are quiktran (ibm's conversational-mode fortran system), and the MAP, Reckoner, and COGO systems. The Reckoner and MAP systems are quite similar to AMTRAN in their provision of a streamlined, applied-mathematics language for scientists and engineers. The COGO system is a problem-oriented language designed to accommodate civil engineering problems.
Two on-line batch-processing systems which use special high-speed compilers consist of the Klerer-May system and Dartmouth's BASIC language. The Klerer-May system is particularly strong in its emphasis upon natural mathematical formatting of its input and output. General Electric has implemented BASIC on a commercial basis.
AMTRAN differs from the preceding systems in various ways. It has been given certain features intended to facilitate future research in applied mathematics. It should be emphasized that AMTRAN is a full-scale ALGOL-type programming system and not a simplified language designed only for small computations or for a narrow range of problems.
Two restricted versions of AMTRAN are presently available which can be used on any IBM 1620 computer with floating point hardware and indirect addressing capabilities.
One version is intended for 1620's with 40,000 digits of core storage while the other is designed for 60,000 digit machines. No special equipment is needed except for the usual console typewriter and a card-reader punch. Copies of these 1620 programs are available from the authors upon request.
Although these restricted versions are designed for small core machines, they possess considerable power. Virtually all of the capabilities of the 1620 version of fortran ii are present, in addition to automatic array arithmetic multi-level programming of operators, rudimentary symbol manipulation capability, the Algol IF test, subscripted subscripts, and above all, the ability to deal with straightforward problems at approximately. the level of classical mathematical analysis. Through an encoding arrangement, this system can store up to 50 console programs or subroutines and can accommodate matrices or two-dimensional arrays up to 25 x 25. (When small desk-top computers become economically feasible, a 4-8,000 word edition of AMTRAN could combine the mathematical power of a digital computer with the simplicity and convenience of a slide rule.)
A more elaborate system utilizing one of the special terminals -described in this article has been implemented on IBM 1620 mod II computer with a disc file.
Although the writers have had very favorable experience with keyboards and visual displays, considerable effort has been expended in rendering AMTRAN compatible with typewriter and teletype input and output, since the latter are cheaper than full-scale AMTRAN terminals.
An extended version written in Algol 60 is currently under development in collaboration with the Burroughs Corporation. This time-sharing AMTRAN incremental-compiler will act like a single program in the multi-processing B5000 or the faster (800-nanosecond cycle time) B6000 computers.
Finally, the Brown Engineering Co. is presently developing an AMTRAN incremental compiler for the IBM 1130 computer. Extract: Hardware Configuration
Hardware Configuration
As previously mentioned, a typical AMTRAN terminal consists of a large keyboard, one or two cathode ray scopes, a Polaroid camera for the scopes, and a special Selectric typewriter. A stylus or "electric pencil" will soon be available to enter graphical information to the computer.
The keyboard has two classes of buttons: labeled buttons which are permanently programmed and unlabeled buttons which are "programmable" by the operator. Sufficient space is provided around the unlabeled pushbuttons so that the user may label them as he wishes on paper overlays provided- for this purpose. Since the number of pushbuttons is necessarily limited, they are used primarily for the more common functions and operators, such as the +, sin, and repeat operators, while mnemonic codes are used to call less commonly used operations such as the error function, or the Newton-Raphson method for solving differential equations.
Since the typewriter is used to call a great majority of operations, the question arises: Why use the keyboard at all? Briefly, when a typewriter is used to enter mathematical equations, entry becomes quite slow and prone to error. A conflict seems to arise in the user between the consideration of the problem and the mechanics of typing. On the other hand, the keyboard is relatively inexpensive, permits considerably faster entry than the typewriter, and provides important software advantages because it enters binary codes directly into the computer, bypassing the label-decoding process. Also, a special keyboard is quite desirable for certain special operations, such as those dealing with graphical displays. Most of the people who have used AMTRAN so far have preferred the keyboard-typewriter combination to the typewriter alone. Nevertheless a typewriter can be used in lieu of the keyboard at some reduction in performance.
Because of the large number of buttons and instructions associated with the keyboard, a full set of instructions has been stored on the disc file and the user may display them any time. A general instructions button has been provided on the keyboard to elicit a display of general instructions on the cathode ray scope and get the user'started. Thereafter, the user can get specific instructions regarding the use of any particular button by pressing the turn page button, followed by the button in question. Thus, the system can explain itself in a self-teaching fashion to the novice user.
The typewriter, used to provide a permanent record of the program, has an 88-character set, which includes most of the Greek alphabet and a large complement of mathematical symbols (Fig. 2). The complete AMTRAN typewriter unit currently under development will have the ability to index the roller upward or downward independent of the carriage return so that mathematical equations may be typed out in the format in which they appear in a mathematics textbook. The typewriter is also used to type out data and results (augmented by the line printer) and, in addition, can serve as a plotter. The reverse indexing feature makes it possible for the typewriter to plot and label a curve in 30-40 seconds.
The stations used by the authors incorporate two scopes so that one scope can present alphanumeric information while the other retains "blackboard" graphical displays. The alphanumeric scope is used to print out instructions and error messages, and while it does not provide hard copy as does the typewriter, its writing speed is much greater. Therefore, it may be used to compose segments of the user's program before entry into the computer. Once the input has been checked, it is released to the computer, at which point a type-out occurs. This rapid writing rate has afforded unexpected benefits in the rapid printing or alphanumeric information in comparison to the slow typewriter. The 5-inch Tektronix storage scopes used for this purpose are inexpensive, afford high resolution, and require no internal buffering; consequently, they can be operated over ordinary voice-grade telephone circuits. (An improved 11-inch scope will be available early next year.) The attached Polaroid camera provides excellent high-contrast photos of the data displayed on the scope face. It would also be possible to employ an on-line plotter which would be shared by several stations. The plotter would provide accurate hard copy plots of any desired data AMTRAN software can be implemented on almost scientific computer of any reasonable size and speed, old or new.
in Datamation 12(10) Oct 1966 view details
in Datamation 12(10) Oct 1966 view details
I. Introduction
Much of the attention given to compiling techniques for algebraic languages has been directed toward producing more efficient object code. automating the process of writing a compiler, and incorporating new features into the programming source languages. An area which has not received comparable emphasis is that of developing techniques to improve the diagnostic capabilities of compilers. This lack of emphasis may be in part due to the fact that the usual specifications of a programming language exclude or give little attention to the need of diagnostic capabilities, for example, the specification of ASA Basic FORTRAN or ASA FORTRAN (see [1]). In this paper CSC is described--the results of a compiler project undertaken at the University of Wisconsin Computing Center (UWCC).
DITRAN (Diagnostic FORTRAN) is a FORTRAN compiler and operating system which provides extended diagnostic capabilities, both at compilation and execution time. One of the purposes in presenting this paper is to outline some of the design features of DITRAN which, when combined with some known algebraic compiling techniques, make it possible to achieve a high degree of success in the detection and analysis of compile time and execution time errors.
DITRAN achieves many of its diagnostic capabilities by extending the notion of a storage unit by associating with each unit a vector of values which describes the status of a variable or array element during the execution of a program. Another purpose of this paper is to discuss, in general, some of the standards or objectives that ought to be set for the diagnostic capabilities of any compiler. DITRAN was written for the CDC 1604 and was put into operation at the UWCC in the summer of 1965.
DITRAN has now received considerable use and the success with DITRAN supports the belief that more attention to this area of compiler development can provide worthwhile dividends. Although DITRAN operates as a compile-and-go batch processing system, many of the techniques employed to maintain information required for diagnostic capabilities ought to be of particular use in an interactive environment involving man and computer via an inputoutput device.
Extract: Background and Objectives
II. Background and Objectives
Manufacturer-supplied FORTRAN compilers normally provide rather efficient object code, provide flexible interaction with the operating systems, and have many sophisticated programming features. However, they are inadequate for the needs presented in the area of finding and correcting errors as quickly as possible. In many instances, the description of an error condition lacks resolution and offers the user little assistance in removing the error other than indicating the statement in which the error occurs. A more serious inadequacy is that many error descriptions are given in terms not understandable to a FORTRAN programmer. For example, (1) several types of compilation time errors are passed on to the assembly phase and emerge as assembly errors which are quite often difficult for the user to associate with his source program, or (2) execution time errors are presented in terms of absolute or relative core locations and machine instructions, all of which are of little or no value to the FORTRAN programmer. Perhaps the most serious inadequacy of the compilers is the inability to detect some error conditions.
These conditions are prohibited by FORTRAN manuals, but the compilers produce no messages for these errors. At execution time, these errors produce undefined results usually dependent upon the residual contents of storage locations of which the programmer is unaware and over which he has no control, for example, subscripting beyond the limits of an array, accessing an entity which has not been assigned a value, or performing real arithmetic on type integer data assigned to a type real entity through an I/O operation or through equivalence associations.
In a university, a large portion of the users of a computing facility are students learning programming and graduate students or research investigators who are not full-time programmers but are faced with the need of using the computer as an educational or research tool. For this group, in particular, the concern of finding and correcting errors in their programs as quickly as possible outweighs the need for efficient object code and sophisticated protramming features. Programs submitted by this group generally involve a rather small amount of computer run time and have rather short useful lives. The ratio of machine time used for program checkout to that used for production is quite high. The interests of this group of users presented a need for a compiler which would provide a maximum of diagnostic information to the progrannner in order to shorten the checkout time.
DITRAN was developed to provide a compiler with extensive diagnostic capabilities. It appeared that developing this compiler would increase the service of the computing facility in several areas. By providing more complete diagnostic information on all errors encountered, the compiler would aid in reducing the number of runs required to check out a program and thus would reduce the time to complete a project. It would also reduce the level of experience required to begin using the computer, and thus increase the availability of the facility to a larger number of users. Finally, by helping students and programmers correct errors without resource to an instructor or consultant, DITRAN would increase the utility of the facility for educational functions.
in [ACM] CACM 10(01) (Feb 1967) 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 IBM Systems Journal, 7(3 and 4) 1968 view details
Dunn and Morrissey (1964) describe an experimental system for remote computing using conversation source-language debugging techniques, developed at the IBM Development Laboratory, New York, N.Y.
in [ACM] ACM Computing Surveys 2(4) Dec1970 view details
in IBM Journal of Research and Development, 25(5), September 1981 25th anniversary issue view details
The author is eminently qualified to have written this paper. She is a long-time employee of IBM, and has written many papers and a definitive book on the development of programming languages. Her account of the contributions of IBM to the development of programming languages is itself a contribution to the subject.
in IBM Journal of Research and Development, 25(5), September 1981 25th anniversary issue view details
Resources
- QUIKTRAN console
