APL (18/apl001)

keyboard

Array-centered programing language 


A Programming Language. Ken Iverson Harvard U 1957-1960. Harvard & IBM 1960-1966.


Probably the most beautiful computer language to date (the only possible rival is LYaPAS, which was heavily influenced by APL).

Designed originally as a notation for the concise expression of mathematical algorithms. Went unnamed and unimplemented for many years, save as "Iverson's Language".

Finally a subset APL\360 was implemented in 1964. APL is an interactive array-oriented language with many innovative features, written using a non- standard character set. It is dynamically typed with dynamic scope. All operations are either dyadic infix or monadic prefix, and all expressions are evaluated from right to left. The only control structure is branch. APL introduced several functional forms but is not purely functional.


Written in FORTRAN IV, and made use of most of FIV's maths library written by Hirondo Kuki



Places
People:
Structures:
Related languages
FORTRAN II => APL   Written using
Iverson's Language => APL   Evolution of
APL => A+   Dialect of
APL => AAIMS   Built on
APL => ADA   Influence
APL => AIDA   Augmentation of
APL => ALICE   Extension of
APL => AML   Influence
APL => AML/X   Positive Strong Influence
APL => APEX   Extension of
APL => APL\360   Implementation
APL => APL2   Evolution of
APL => APLBAGS   Extension of
APL => APLBOL   Subset
APL => APLG   Extension of
APL => APLGOL   Extension of
APL => APLOMB   Augmentation of
APL => APLSF   Extension of
APL => APPLE   Implementation
APL => AQL   Extension of
APL => associons   Influence
APL => D4   Extension of
APL => DELISA   Strong Incorporated some features of
APL => DPL   Incorporated some features of
APL => FAC   Augmentation of
APL => Fornax   Extension of
APL => Glee   Extension of
APL => GPL   Dialect of
APL => IDAMS   Written using
APL => IVSYS   Implementation
APL => J   Evolution of
APL => K   Evolution of
APL => LOTIS   Incorporated some features of
APL => LPG   Influence
APL => LRLTRAN   Influence
APL => LYaPAS   Positive strong Influence
APL => MFL   Based on
APL => microAPL   Implementation
APL => More array theory   Incorporated some features of
APL => MUMBLE   Based on
APL => OSU APL   Evolution of
APL => PAT   Implementation
APL => Poplar   Derivation of
APL => PPL   Extension of
APL => PREDULA   Influence
APL => S   Influence
APL => SAPL   Augmentation of
APL => SAX APL   Extension of
APL => Scratchpad   Incorporated some features of
APL => SDL   Influence
APL => Squigol   Influence
APL => STSC APL   Implementation
APL => TESI   Extension of
APL => Vector PASCAL   Influence
APL => VSAPL   Implementation
APL => Wyoming structured APL   Augmentation of

References:
  • Iverson, K. E. "A programming language" pp345-351 view details
          in [AFIPS JCC 21] Proceedings of the 1962 Spring Joint Computer Conference in San Francisco, Ca. SJCC 1962 view details
  • Iverson, K.E. "A common language for hardware, software and communications" view details
          in [AFIPS JCC 22] Proceedings of the 1962 Fall Joint Computer Conference FJCC 1962 view details
  • Iverson, Kenneth E. "A Programming Language", Wiley, 1962. view details
          in [AFIPS JCC 22] Proceedings of the 1962 Fall Joint Computer Conference FJCC 1962 view details
  • Landin, Peter review of Iverson 1962 AFIPS (APL) view details Abstract:
    Roughly speaking, it is possible to classify proposals concerning what a computer user writes into three sorts: (a) the "primitive" concepts (such as the class of real numbers, dividing, taking the square root, exponentiation, assignment, making a selection determined by the truth of a proposition, assembling components to form a block); (b) the "names" by which the primitive concepts are indicated (such as "real", "/" "a/", the configuration of superscription, ":=", "if ~. then ~. else A", "begin A; [ Book ] ; end"); (c) the rules about constructing compound expressions (such as whether operators are prefixed or infixed, and which expressions can occur as their arguments) and the rules about construing a given piece of text (such as precedence rules).

    Also roughly speaking, it is possible to classify the expressions the user writes into two sorts: (1) "descriptive" ones, such as right-hand sides, subscripts, data descriptions (which describe classes of data structures), lambda-expressions (which describe specific functions); (2) "imperative" ones, such as assignments, declarations, routines, job descriptions (which describe specific jobs).

    The proposals of the paper under review are mostly about (a) and (b) rather than (c), and are mostly about (1) rather than (2). They choose certain specific "primitives" and certain "names" for denoting these primitives.

    The chosen primitives include some eminently deserving funetions for selecting components from vectors, matrices and trees, and some functions for constructing and transforming them. They also include some interesting higher level functions for iterating and mapping with given functions through the components of given arrays. The chosen names are some familiar, and less familiar, infixed punctuation marks (including two new roles for "/"; some familiar, and less familiar, configurations (including two new roles for superscription); and some Greek letters.

    For example: " +/x" denotes the sum of members of the vector x. "Ai" and "Ai" respectively denote the ith row and column of the matrix A. Dyadie functions such as +, X are generalized to apply term by term to vectors. So "+/(A' X Bj)" denotes the

    (i, j)-th element of the matrix product AB. The most flashy innovation is a configuration which permits, for instance, this matrix product to be written "A X+ B", and has numerous other meaningful applications.

          in ACM Computing Reviews 5(04) July-August 1964 view details
  • Rose, A. J., The Use of APL for Describing Programs at Many Levels of Detail, IBM Corp., RC 1700, T. J. Watson Research Center, York town Heights, N.Y. (Oct., 1966). view details
          in ACM Computing Reviews 5(04) July-August 1964 view details
  • Newell, Alan, Jay Earley and Fred Haney "*l manual" Carnegie Institute of Technology June 26, 1967 view details Extract: Conversational languages
    The situation normally faced by the designer of a system is that he has a set of distinct facilities ? such as languages, editors, debuggers, timing packages, and cross-reference programs. Each of these is created with a separate set of linguistic and interactive conventions. There is integration only at the level of the underlying operating system, seen by the user-designer as a single uniform command language. On the other hand, general interactive systems from JOSS (Shaw 1965) onward have adopted the other position by integrating all the facilities with the main language system. LISP, APL and l-* belong in this latter category, along with a less well-known system called LCC (Perlis, Mitchell, and VanZoeren 1965). Though at heart a JOSS-like system, LCC has many of the features of a standard HLL, and thus represents 3 rather unique marriage of HLL constructs with the philosophy of complete integration.
          in ACM Computing Reviews 5(04) July-August 1964 view details
  • Sammet, Jean E., "Roster of Programming Languages 1967" view details
          in Computers & Automation 16(6) June 1967 view details
  • Iverson, K.E. "The use of APL in statistics" pp285-294 view details
          in R.C. Milton and J A. Nelder (Eds.) "Statistical Computation" Academic, New York, 1969 view details
  • Reinfelds, J. "AMTRAN: An Interactive Computing System", pp537- 542 view details Extract: COMPARISON WITH OTHER HIGH LEVEL LANGUAGES
    COMPARISON WITH OTHER HIGH LEVEL LANGUAGES
    A comparative study between AMTRAN and other
    high level languages has to be divided into two parts. Only language features can be compared with batch mode languages, whereas the whole AMTRAN- system can be taken into account for a comparison with other interactive systems.
    Batch mode languages
    Most likely, PL/1, ALGOL, or FORTRAN would be used to solve mathematical, technical or scientific problems in batch mode. A comparison with AMTRAN is not really feasible as the basic philosophy and design principles of batch mode languages are completely different from AMTRAN.
    Since language development goes more and more in the direction of powerful general purpose languages, it becomes more and more difficult, time consuming, and cumbersome for the nonprogrammer to make the first step towards use of a computer. But even for the experienced user, the three languages mentioned above do not provide the convenience and facilities in programming that AMTRAN does. They need type and dimension declarations; the flexibility in changing types and dimensions at run time is lacking; and they do not have AMTRAN's array handling capabilities.
    PL/1 with its default philosophy, its various types of storage allocation, and certain automatic array arithmetic features is close to AMTRAN's facilities and philosophy of programming convenience. On the other hand, it is inconvenient for the user to keep track of storage allocation  problems in writing recursive or re-entrant programs or in using arrays with computed origin.
    PL/1 is truly a general purpose programming language. It is designed for programming needs in science, engineering, data management, and business. AMTRAN, on the other hand, is a special purpose programming language for mathematical, scientific, and technical applications and has not been designed to compete in general with a language like PL/1. It is not intended to handle extensive data; therefore, it does not need powerful I/O-capabilities and sophisticated formatting facilities. But it can compete or even perform better within the limits of its special purpose.
    Interactive systems
    An interactive console system fills the gap between a desk top calculator and conventional batch mode
    computer programming. On one hard, it has to give immediate answers to simple request on the other hand,  it has to provide powerful programming capabilities.
    A milestone in the development of interactive systems was the Culler-Fried-Systen . which strongly influenced the early AMTRAN development. Prof. Culler's system represents a highly powerful multi-console system. A disadvantage is that it does not stay close to the mathematical notation, and it is not simple and easy to learn.
    CPS is a conversational subset of PL/1. It has a calculator mode and a program mode and is a useful conversational system although it does not have AMTRAN's flexibility and power in a ray and function handling.
    Iverson's language APL (A Programming Language) is a more formal approach to application programming. It is particularly useful for classical mathematical applications, and it has been implemented as a powerful interactive time-sharing system. The language has features such as array arithmetic, programming capabilities, and a large set of primitive operators including matrix handling operators. An extenstive set of special symbols is used instead of keywords. Thus, a special typewriter is necessary. The proponents of APL claim that its source code is more efficient per statement than that of any other programming language. On the other hand, it is less readable. One has to learn special symbols instead of using mnemonics. For example, the quad [] in APL is less informative as an output operator than the TYPE in AMTRAN.
    Major disadvantages are that APL does not follow classical mathematical notation, there is no hierarchy among operators, and the order of execution of statements is from right to left. This meat the mathematician and scientific nonprogrammer must convert his formulas, written in normal textbook format, into the APL-notation, and the programmer experienced in any other language is even more confused. APL is a language which requires both care and training for simple applications.

          in [AFIPS] Proceedings of the 1970 Fall Joint Computer Conference FJCC 37 view details
  • Stock, Karl F. "A listing of some programming languages and their users" in RZ-Informationen. Graz: Rechenzentrum Graz 1971 16 view details Abstract: 321 Programmiersprachen mit Angabe der Computer-Hersteller, auf deren Anlagen die entsprechenden Sprachen verwendet werden kennen. Register der 74 Computer-Firmen; Reihenfolge der Programmiersprachen nach der Anzahl der Herstellerfirmen, auf deren Anlagen die Sprache implementiert ist; Reihenfolge der Herstellerfirmen nach der Anzahl der verwendeten Programmiersprachen.

    [321 programming languages with indication of the computer manufacturers, on whose machinery the appropriate languages are used to know.  Register of the 74 computer companies;  Sequence of the programming languages after the number of manufacturing firms, on whose plants the language is implemented;  Sequence of the manufacturing firms after the number of used programming languages.]
          in [AFIPS] Proceedings of the 1970 Fall Joint Computer Conference FJCC 37 view details
  • Rosen, S. "Programming Systems and Languages 1965-1975" view details Abstract: In spite of impressive gains by PL/I, Fortran and Cobol remain the languages in which most of the world's production programs are written and will remain so into the foreseeable future. There is a great deal of theoretical interest in Algol 68 and in extensible languages, but so far at least they have had little practical impact. Problem-oriented languages may very well become the most important language development area in the next five to ten years. In the operating system area all major computer manufacturers set out to produce very ambitious multiprogramming systems, and they all ran into similar problems. A number of university projects, though not directly comparable to those of the manufacturers, have contributed greatly to a better understanding of operating system principles. Important trends include the increased interest in the development of system measurement and evaluation techniques, and increased use of microprogramming for some programming system functions. DOI
          in [ACM] CACM 15(07) (July 1972) view details
  • Sammet, Jean E., "Roster of Programming Languages 1972" 18 view details
          in Computers & Automation 21(6B), 30 Aug 1972 view details
  • Elson, M. Concept of programming languages, Science Research Associates, Palo Alto, Calif., 1973 view details
          in Computers & Automation 21(6B), 30 Aug 1972 view details
  • Falkoff, AD and Iverson, KE "The Design of APL" IBM Journal of Research and Development 17(4) pp324 view details Abstract: This paper discusses the development of APL, emphasizing and illustrating the principles underlying its design. The principle of simplicity appears most strongly in the minimization of rules governing the behavior of APL objects, while the principle of practicality is served by the design process itself, which relies heavily on experimentation. The paper gives the rationale for many specific design choices, including the necessary adjuncts for system management.  

      



    External link: Online copy
          in Computers & Automation 21(6B), 30 Aug 1972 view details
  • Stock, Marylene and Stock, Karl F. "Bibliography of Programming Languages: Books, User Manuals and Articles from PLANKALKUL to PL/I" Verlag Dokumentation, Pullach/Munchen 1973 44 view details Abstract: PREFACE  AND  INTRODUCTION
    The exact number of all the programming languages still in use, and those which are no longer used, is unknown. Zemanek calls the abundance of programming languages and their many dialects a "language Babel". When a new programming language is developed, only its name is known at first and it takes a while before publications about it appear. For some languages, the only relevant literature stays inside the individual companies; some are reported on in papers and magazines; and only a few, such as ALGOL, BASIC, COBOL, FORTRAN, and PL/1, become known to a wider public through various text- and handbooks. The situation surrounding the application of these languages in many computer centers is a similar one.

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

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

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

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

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

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

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

    Graz / Austria, May, 1973
          in Computers & Automation 21(6B), 30 Aug 1972 view details
  • Iverson, Falkoff, Abrams, Breed, Moore: "The Origins 0F APL"; 1974; view details
          in Computers & Automation 21(6B), 30 Aug 1972 view details
  • Leavenworth, Burt M.; Sammet, Jean E. "An overview of nonprocedural languages" pp1-12 view details Abstract: This paper attempts to describe some of the basic characteristics and issues involving the class of programming languages commonly referred to as ?nonprocedural? or ?very high level?. The paper discusses major issues such as terminology, relativeness, and arbitrary sequencing. Five features of nonprocedural languages are described, and a number of specific languages are discussed briefly. A short history of the subject is included.

          in Proceedings of the ACM SIGPLAN symposium on Very high level languages, March 28-29, 1974, Santa Monica, California, United States view details
  • Iverson: "APL In Exposition"; 1976; view details
          in Proceedings of the ACM SIGPLAN symposium on Very high level languages, March 28-29, 1974, Santa Monica, California, United States view details
  • Licklider, J.C.R. "USER-ORIENTED INTERACTIVE COMPUTER GRAPHICS" Proceedings of the ACM/SIGGRAPH workshop on User-oriented design of interactive graphics systems Pittsburgh, PA 1976 pp89-96 view details Extract: Graphics Embedded in LISP and APL-Like Languages
    Graphics Embedded in LISP and APL-Like Languages
    Graphics has dominated most of the computer systems (such as systems for computer aided design and systems for the layout of LSI chips) that have made extensive use of interactive graphics, and the languages through which users have interacted with such systems have been primarily graphical languages. The languages in which such systems have been implemented, however, have usually been ordinary programming languages with little or no graphics capability of their own. It seems to me that there is an important middle ground, a place for systems that employ both graphical and alphanumeric input and output and that are operated or controlled through mixed media.
    It seems to me, also, that there is a need for languages that can serve both as programming and interaction languages and that incorporate the essential graphic forms and graphics operations along with the data structures, control structures, and basic operations required in programming systems and in interacting with systems that have been programmed.
    My favorite candidate language for the role just described is a derivative of LISP called "MDL" ("More Data-structures than Lisp"). But instead of pushing it, particularly, I want to point in the general direction of LISP and APL, languages that have implementations with both interpreters and compilers, the interpreters being in fact complete programming systems with built in libraries, documentation subsystems, debugging aids, and so on -- and the compilers being already reasonably efficient in some instances and in principle very amenable to high optimization.
    I think that some characteristics of LISP and APL are of the essence of user orientation, and I think that interactive computer graphics can correct some of the characteristics that are not. Some of the good features of LISP are the simplicity of its data and control structures, the essential modularity of LISP programs (functions), the fact that LISP programs are processible as data by other LISP programs, and the fact that a single program can include both interpreted and compiled parts. Some of the good features of APL are its abundance of array operators and the terseness with which complex procedures can be expressed.
    A few bad features should be acknowledged: LISP has too many parentheses and too many terms that are not properly selfexplanatory, and APL reads backwards, but graphical representation could cure those ills.
    What I advocate, then, is a graphics-augmented LISP-like or APL-like language that can be used both to program and to operate interactive graphics systems.
    For nonprogrammer users, some of the more sophisticated parts of the language would ordinarily be held back, but essentially there would be a single, uniform language for graphics and nongraphics, for programming and operation. The main consideration that forces me to qualify my claims for the value of such a language is that both LISP and APL complications require much further development before they can provide the efficient code required in the final stages of system development. However, as Bruce Daniels is arguing very convincingly [3], the greatest optimization can be achieved with the highest-level language, and the future therefore looks good for efficiently compiled code from such a language as I am advocating.
          in Proceedings of the ACM SIGPLAN symposium on Very high level languages, March 28-29, 1974, Santa Monica, California, United States view details
  • Perlis , Rugaber: "The APL Idiom List"; 1977; view details
          in Proceedings of the ACM SIGPLAN symposium on Very high level languages, March 28-29, 1974, Santa Monica, California, United States view details
  • Falkoff, A.D. and Iverson, K.E. "APL language summary" view details
          in SIGPLAN Notices 14(04) April 1979 including The first ACM SIGPLAN conference on History of programming languages (HOPL) Los Angeles, CA, June 1-3, 1978 view details
  • Falkoff, A.D. and Iverson, K.E. "The evolution of APL" view details
          in SIGPLAN Notices 14(04) April 1979 including The first ACM SIGPLAN conference on History of programming languages (HOPL) Los Angeles, CA, June 1-3, 1978 view details
  • Holmes, WN "Is APL a programming language?" view details Abstract: A Journal article entitle 'is APL a viable programming language?' (Earnshaw, 1975), seemed to answer its question with a Yes. This article, written by an APL enthusiast, suggests the answer should have been No, not because APL is not viable, but because it is not a programming language. This suggestion is supported by an examination of what APL is, and of what programming is. The conclusion is drawn that programming, in the occupational sense, should be distinguished form calculation, and that APL is suited to calculation but not to programming. External link: Online copy
          in The Computer Journal 21(2) May 1978 view details
  • IBM: "APL Programming Guide: Vector Operations"; 1978; view details
          in The Computer Journal 21(2) May 1978 view details
  • Sammet, Jean E "Roster of programming languages for 1976-77" pp56-85 view details
          in SIGPLAN Notices 13(11) Nov 1978 view details
  • Weaver, KR review of Holmes 1978 view details Abstract: W. N. Holmes' view is that APL is not a viable programming language, but rather an algebraic language for calculations. In an attempt to address this theory, Holmes drifts from the issue to what appear to be his pet desires for changes and extensions to the notation. APL is described as being concise, powerful, flexible, and suited for a changing environment. The reader could easily conclude that the paper's outcome will determine that APL is the only programming language, and that the other so-called programming languages are sorely lacking.
          in ACM Computing Reviews 19(10) October 1978 view details
  • [SigAPL] "APL79 Conference Proceedings" view details
          in ACM Computing Reviews 19(10) October 1978 view details
  • Berry Et Al: "APL And Insight"; 1979; view details
          in ACM Computing Reviews 19(10) October 1978 view details
  • Iverson, Kenneth E. "Operators" ACM TOPLAS 1(2) October 1979, pp161-176 view details
          in ACM Computing Reviews 19(10) October 1978 view details
  • McDonnell, E. E. "The socio-technical beginnings of APL" ACM SIGAPL APL Quote Quad 10(02) December 1979 pp13-18 view details Abstract: This paper gives some of the history of the early implementations of APL, and concentrates on the system aspects of these implementations, paying special attention to the evolution of the workspace concept, the time-sharing scheduling strategy, and the handling of the terminal. It contrasts the development of APL with the development of other time-sharing systems which were being built at the same time. External link: Online copy Extract: Introduction
    Introduction
    We have grown so accustomed to using APL at terminals of time-sharing systems that it is possible to forget that there is no inherent necessity in the way we use it. It is such a fortunate marriage, however, that it may be useful to tell something of the circumstances that led to it.
    Extract: Early time-sharing systems and APL
    Early time-sharing systems and APL

    The PAT system written by Herb Hellerman [2] was an interactive system, but not a time-sharing one. Reading the paper that describes it today, it seems quite crude, since it involved the user in declarations, and employed only the ordinary typewriter characters on the console of the IBM 1620.

    Nevertheless, it was relatively easy to learn and to use, and helped to clarify a number of points in the developing language. Falkoff and Iverson describe the next series of steps in a rapid summary: When the work on the formal description of System/360 was finished in 1964 we turned our attention to the problem of implementation. This work was brought to rapid fruition in 1965 when Lawrence M. Breed joined the project and, together with Philip S. Abrams, produced an implementation on the 7090 by the end of 1965. Influenced by Hellerman's interest in time-sharing we had already developed an APL typing element for the IBM 1050 computer terminal. This was used in early 1966 when Breed adapted the 7090 system to an experimental time-sharing system developed under Andrew Kinslow, allowing us the first use of APL in the manner familiar today. By November 1966, the system had been reprogrammed for System/360 and APL service has been available within IBM since that date. [3]

    It is worth pointing out that the timesharing system developed under Kinslow [4] was not the first system under which the APL group tried to put the Abrams-Breed interpreter. There was a system called M44, the first IBM experiment with a virtual-memory machine, being developed at their T.J. Watson Research Laboratory. The APL group at Research naturally thought of using this when they were looking for a home for the interpreter. However, they ran into a disastrous limitation--the M44 system took seven bits from the terminal communicating with it and passed six of them on to the application program. When the APL group asked if they could have all seven bits passed along, they were turned down with the explanation that "this is against the M44 design philosophy".

    Somewhat reluctantly, the APL group decided to investigate the suitability of the TSM system, being developed by a group fifteen miles away, at another IBM laboratory in Yorktown Heights, called the Mohansic Laboratory. The TSM system was perfectly happy to give the application program complete control over what was sent in, including all seven bits from the terminal, and thus the Iverson group decided to use it for the implementation. The TSM system, after a shaky beginning, had settled down into a reasonably usable system by late 1965, and was able to support about twenty terminals on a modified IBM 7090, the 7093. Furthermore, remote access to this system was possible, so that people were able to dial into it from all over the country, using the IBM tie-lines. Iverson and Falkoff were teaching at that time at the IBM Systems Research Institute in New York City (forty miles away), and were able to use the implementation (called IVSYS) on TSM in their classes. This led to a broad dissemination of Iverson notation, since people came to the Systems Research Institute from all parts of IBM.

    It was just at this time, however, that IBM had become extremely interested in time sharing as a commercial venture~ because MIT and Bell Laboratories had decided that IBM's brand-new System/360 was not the best vehicle for their next generation of timesharing systems, and had decided instead to order computers for this purpose from General Electric. Since these were very prestigious institutions, it became a matter of great importance in IBM to show that IBM did have competence in the area of programming computers to do time sharing. A time-sharing group was formed, and the people who had been at work in Mohansic on the TSM system became the nucleus of it, later to be joined by several hundred more. Part of this nucleus was dedicated to keeping the 7093 TSM system running.

    At the same time, Ken Iverson was just completing his book Elementary Functions [5]. One part of the publication effort was an answer book to the problems. His son Eric was preparing this, using IVSYS on TSM to verify the answers. The manager of the new time-sharing activity at Mohansic (which came to be called TSS), needing people to work on the design and implementation of the product, decided that he would terminate the 7093 TSM service and reassign those people to the new 360-based effort. This was resisted unsuccessfully by many of the people who were working on TSM. It was also resisted by Ken Iverson, who protested that his work depended on the continuing availability of TSM. The result was that the termination of TSM was delayed for thirty days in order to allow Ken's answer book to be completed. During that time all the costs of running the 7093 were paid for by Iverson's project.

    It now was clear to the Iverson group that they needed somehow to transfer their work to the new generation of IBM equipment. They obtained access to a 360/50 which had been installed at Research, with two small disks (2311's). Also, because of a general interest in time sharing around Research, there was an adequate supply of terminals to draw upon, either the older I050's or the newer 2741's. There was, however, one important difficulty in that no communications controller was available to them; a time-sharing system couldn't function very well without one of these!

    At this point, something happened that was to have the greatest significance for APL. The Chairman of the IBM World Trade Corporation--Arthur K. (Dick) Watson, son of Thomas J. Watson, Sr.--was an alumnus and board member of the Hotchkiss School. While on a visit to Notchkiss, Dick Watson saw students using a time-sharing terminal connected to a computer at Dartmouth College. He was dismayed to learn that the computer at Dartmouth was a GE computer, not one of IBM's. This was, of course, the original BASIC system, developed at Dartmouth in the mid-1960's [6]. Watson came back to his office and ordered that something be done to see that the Hotchkiss students were able to use an IBM computer in the same way that they were using the GE computer. Nervous staff members scampered through IBM, looking for the right thing to use in competing with the GE equipment.

    The first thing they found was a product called QUIKTRAN. This was a system which permitted remote-terminal entry of FORTRAN card images for subsequent compilation and execution. It was sometimes known as SLOWTRAN, and was not the most reliable system ever built. The terminals it used had rectangular type boxes which it jiggled periodically during processing, so that the user would know that the system hadn't collapsed. The Hotchkiss people were unimpressed with QUIKTRAN, and the IBM staff people had to find something else. It was then that Dick Watson heard of the system called IVSYS that had been used at the Systems Research Institute and which many people there had thought was a very convenient, user-oriented system. This information probably came from that fine man John McPherson, a vice-president of IBM and Director of the Systems Research Institute. He had attracted Ken Iverson and Adin Falkoff to the faculty of the Institute, was a constant promoter of the use of Iverson notation, and was also the only vice-president of IBM who had an APL terminal in his office. (Although now retired, he continues his interest in and association with APL, and has an APL terminal in his home.)

    On tracking down the information on IVSYS, it turned out that it had come to an end when the hardware it ran on had disappeared (the hardware was put out on a shipping platform one morning and it was taken away, no one knew where--just dropped into a void), but that those responsible for it were eager to provide a similar system for IBM's new generation of computers, the System/360. Upon investigating this further, it was found that the group at Research was indeed eager to undertake the new implementation and had its eyes on a 256-kilobyte 360/50 that had been installed there, but that a key ingredient, a communications controller, was not available. Larry Breed and Roger Moore had already started the 360 program design and implementation, but had to use a 360/40-2702 combination located at the Mohansic laboratory in order to do the initial debugging of their terminalhandling code.

    The reports of the capabilities of IVSYS on TSM were so glowing that Dick Watson used his influence, and soon there was the promise of the delivery of a 2702 communications controller. This arrived without any cables, and it took a good deal of phoning before the cables were finally discovered in a warehouse in Poughkeepsie, APL Quote Quad 10 2 14 December 1979 whereupon Larry Breed hopped in his Rover 2000 to make the 50-mile trip up the Taconic Parkway to pick them up and bring them back to Research°

    The implementors (who by now included Dick Lathwell) were racing against a time limit in order to get a working system. A class in system design~ using APL, had been scheduled for the beginning of November at the NASA Ooddard Center near Washington, DoC.~ and it was critical that Iverson and Falkoff have a working system to use in teaching the class. It was a very close race. In order to use the Research system from Goddard~ it was necessary that the appropriate telephone-company data sets be available. However, the telephone company serving Goddard was unable to provide these, so ten I03A2 data sets were taken by car 250 miles from Yorktown Heights to Goddard by a friendly member of the Research maintenance staff.

    On the weekend before the class was to start, the 2702 failed dramatically, and it took two days to locate the expert, who fixed the trouble (a bad clock card) in ten minutes. Furthermore, the system-residence file was accidentally erased, and Dick Lathwell learned very quickly how to generate the host operating system (DOS) and to do something never done before-- install APL! On top of that, a catastrophic error developed in the APL supervisor while Roger Moore, who had implemented it, was away in Europe. Dick Lathwell then had to learn the code for the multiplexor channel as well. Falkoff, who was at Goddard, kept calling Breed and Lathwell at Research every ten minutes to see whether it was yet possible to connect to the system. Finally, at eight in the morning of November 11, just as the first class was to begin, it was possible to test a terminal connection. It took a lot of confidence on Falkoff and Iverson's part in the capabilities of Breed, Moore, and Lathwell to allow them to undertake that class. Performance of two earlY time-sharing systems

    A visitor to IBM's laboratories in Yorktown Heights, N.Y. at about this time could have seen early versions of two different time-sharing systems. The large machine room in the Research Laboratory contained a model-360/67 system, with 2 megabytes of memory and several 2301 fast drums used for paging, which was being used as a test site for the development of TSS. Across the hall from this room was a much smaller room, containing a 360/50, with 256 kilobytes of memory, using two of IBM's smallest disks, the 2311, for all external storage. This was being used to deliver an experimental service which used the acronym APL.

    It is instructive to contrast the two systems. The number of people at work on TSS was in the hundreds; the group at work on APL never exceeded ten people. TSS was a key project in IBM, and enormous material resources were expended on it; on the other hand, every scrap of resource used in the development of APL had to be scavenged or fought for. At one time a single 2311 disk pack meant the difference between having to shut down the service or allowing it to continue. Nevertheless, despite the disparity in the number of people at work on the two projects, and in the material resources available to each, the giant TSS project was in trouble, whereas the minuscule APL project was bounding from success to success like a chamois on the crags of the Alps.

    The TSS project was late in its schedules. The system was unreliable, not being able to stay up for more than an hour at a time. It was a struggle to get one terminal supported, then another struggle to get two terminals supported. Terminalby- terminal its capacity moved slowly upward, each new terminal supported being cause for celebration. The response time was abysmally slow, with minutes going by between input and reaction. The command language, which took a complete book to describe, turned out to be unusable; it had to be thrown away and a new one, equally big, was designed from scratch. The APL system, on the other hand, began by supporting 30 terminals, with a subsecond reaction time for more than 97% of all inputs. It went from supporting 30 terminals to supporting 64 merely by adding equipment and increasing the size of certain tables in memory, maintaining the same subsecond reaction time for 97% of all inputs. Starting from a scheduled uptime of only six hours a day, it went effortlessly to a schedule that eventually went seven days a week, sixteen hours a day during the week and continuously over the weekend. The system commands in APL were a mere handful, and the error messages that could be given were listed on a single sheet of paper.

    The APL system was so reliable that a special rule had to be made by IBM to allow it to run unattended. No other IBM system had been so trustworthy that anyone had ever thought of doing this. It was usually over the weekends that the system ran unattended. To emphasize the point that a new dimension in computer systems had arrived, the APL-machine-room lights were turned off when the system was running like this, so passers-by would look into a darkened room and see just the lights on the console blinking.
    Extract: The workspace concept
    The workspace concept

    One of the features of the TSM system, the first time-sharing host for IVSYS, the predecessor of APL, was that the user's APL Quote Quad 10 2 15 December 1979 active body of work could be given a name and stored in a common file with the work of other users. Furthermore, any user could obtain access to the work files of any other user, if that user permitted it to happen. When people used IVSYS, the typical method of operation for a new user was to load the IVSYS file, perform some work with it and then, in order to save it~ rename the file (using TSM's command language) and save the whole collection; the next time the work was wanted, the user would load the new file in place of IVSYS. This crude but effective technique was the precursor of the workspace and library concepts of APL, just as the command language of TSM was the rough precursor of the system commands of APL. Even the sign-off message of TSM was taken over intact to become the familiar sign-off message of the APL system.

    Not enough has been written about how effective and how necessary were the ideas of the workspace and of sharing work in the interactive environment of APL. The workspace acts as a convenient unit of programs and data, and provides very effective name isolation, so that a user can have many different kinds of work available in an APL system, and yet not have to worry about naming conflicts. Most importantly, as we shall see, the uniform size of workspaces played a very important role in making APL's superior performance possible. In addition, by providing to the interpreter a private area where the user's requests for work could be performed, it made possible the establishment of programming conventions that allowed effective time-sharing to be done without requiring relocation or virtual-memory hardware. In the discussions that led MIT to decide not to use the System/360 for the successor to their first-generation time-sharing system, CTSS (a contemporary of IBM's TSM), the MIT designers made clear that virtual memory was an integral part of their computer plans. The IBM point of view was presented to them personally by one of the chief architects of System/360, Gene Amdahl, who made the same argument in print: Dynamic relocation of programs and/or data areas is a problem occurring in time-shared multiprogramming applications. In such an application, a given latent program may be displaced from storage either by the requirements of an active program or a program of higher priority. At a later time, it is desired to bring this program back into storage and to resume its execution. At this point, two alternatives exist: delay the return of the displaced program until its previous residence areas become available, or relocate this program to regions of storage currently available.

    The former alternative involves further delay for the displaced program; the latter alternative requires that all address-like information be identified and appropriately modified° It is easy enough to define an automatic dynamicrelocation addressing technique which entails considerable penalty in either hardware or timed or in both. The challenge is to provide an addressing technique whose inherent characteristics permit the adoption of programming conventions that are capable of programmed relocation with reasonable efficiency. [7]

    The penalty Amdahl mentions may be as high as 20% on current machines; that is, a sequence of instructions run with relocation off will run as much as 20Z slower when relocation is turned on. Although Amdahl~ along with Gerrit Blaauw and John Cocker had helped design the relocation feature for the 360/67~ he mistrusted the virtual-memory concept and laid down a rule which I have come to call Amdahl's law: The larger the difference between virtual memory and real memory, the worse the performance of the system. His simulations showed that a system which used programming conventions rather than hardware for relocation could be written without suffering any greater multiprogramming queuing delays and thus, since it would not suffer the hardware relocation penalty, would run as much as 20% faster. His arguments did not prevail, and not only did the TSS project go forward using the 360/67, but eventually the entire line of large IBM computers acquired virtual-memory hardware, beginning with the System 370/158 and 168.

    The relevance of all this to the history of APL is that APL fully justified Amdahl's claim that efficient programming techniques could be used with System/360 to permit these machines to do effective time sharing. It is probably safe to say that no more effective time-sharing systems have been built than those which run APL. It is remarkable that even today, when almost the entire population of large IBM and IBMcompatible machine users have begun to use operating systems which require relocation, there are still APL systems which run on these machines without the aid of relocation or virtual memory. For example, the I.P. Sharp APL system runs on a pair of 4-megabyte Amdahl V6-II computers in Toronto, using the relatively primitive Sharp-DOS operating system, and runs, of course, unrelocated. This means that if the same APL interpreter were to run on the same machinery, but under a virtual-memory operating system such as VM or MVS, it would run as much as 20% slower. APL was able to do an effective job of software relocation for several reasons, but the fact that the monolithic workspace was the unit of interpretation is probably the most important of these.
    Extract: APL's scheduler
    APL's scheduler
    In a time-sharing system, the key to good performance lies in the way the external storage devices are used. Here the contrast between the TSS and APL systems was most remarkable. On TSS, one could look through the glass windows of the disk devices and watch the motion of the arms. These jerked rapidly back and forth, swooping over wide areas of the disk faces, with the appearance of someone in the grip of St. Vitus' dance. On the APL disks, one arm would be moving quite regularly, like the escapement mechanism of a clock, as it went from one track to the adjacent track, then to the next track, and so on, over fifty or so tracks in several seconds, and then retracted to the beginning and started the cycle over again. Sometimes the total excursion was more, sometimes less; it was so regular that an experienced person like Roger Moore, who was principally responsible for the APL supervisor, could tell how many users were signed on by watching it.
    The reason for the behavior of the disks on the TSS system is that "demand paging" was being used to manage the computer's memory, and the level of technology at the time was such that this was one of the least efficient ways of managing computer memory. I won't go into the details of demand paging, or discuss the virtualmemory question at all, other than to say that the question of how best to manage computer memory in a multiprogramming environment is still being discussed today.
    The APL scheduler gained much of its effectiveness from its simplicity, and its simplicity derived from the fixed-size workspace (which was initially 36,000 bytes, or slightly less than one 2311 cylinder, in size). The scheduler was designed by Larry Breed and Roger Moore, and implemented by Moore. It had three components, each completely unaware of the other two. One scheduled the swap channel for writes, one scheduled it for reads, and one scheduled the computer. The memory of the computer included a certain number of areas of contiguous memory, each large enough to accommodate a workspace; these areas were called slots. The swap-write component of the scheduler looked to see if the swap channel was idle. If it was, and if there wasn't an unused slot, it chose the active workspace in one of the slots to be written out. The one it chose was either a workspace which had finished execution, or whose time slice had ended, or, if there were none of these, the one that had been in the memory longest. It chose the cylinder where this workspace was to be written by finding the vacant cylinder closest to or at the current position of the disk arm. More often than not, the disk arm was already positioned at a vacant cylinder, as a result of the action of the next part of the scheduler to be described, the swap-read component. If there was an unused slot already in memory, it didn't bother creating another one.
    The second part of the scheduler, the swap-read part, also did nothing if the swap channel was busy. If it was idle, however, it tried to find a workspace on the swap disk that should be brought in. Half of the time, it went first through those workspaces which were associated with a user who had an unserviced input, and only if it found none of these would it search out a workspace representing a swapped-out user who was currently in a compute-bound state. On every other excursion of the disk arm, it would play no favorites. The way it chose which workspace to read was quite simple. It merely looked for the workspace satisfying its criteria (recent input, or any, depending on the kind of excursion it was on) which was closest to the current position of the disk arm. This was often the workspace on the next adjacent cylinder, and thus the disk-arm motion was minimal. The swap-read part of the scheduler, having chosen which workspace to read in, ended its job, and the computer-dispatcher portion took over. Note that the swap-read and swap-write portions worked in complete harmony with each other, but completely unaware of each other's existence--there was no direct communication between them.
    The computer-dispatcher part of the scheduler had a very simple job. It simply moved a pointer in a cyclic fashion from one slot to the next eligible slot, indicating which workspace was to be the target for the interpreter when next the interpreter was entered. That's all there was to it, and a more harmonious or smoother-working scheduling technique has not come to my attention.
    Extract: Terminal handling
    Terminal handling
    Although the swap-disk scheduler was the key component of the supervisory system as far as overall system performance is concerned, the user at the terminal was just as much concerned with superficial aspects of the terminal handling in forming judgments about how well the system was performing.
    One clever feature of this early APL was the way in which the character used to indicate the presence of a system command, namely the right parenthesis, was also used to distinguish what kind of terminal the user was at. On the TSS system, a separate bank of telephone numbers had to be set up for each kind of terminal that the installation wanted to support, because different terminals used different transmission codes for the characters. APL Quote Quad 10 2 17 December 1979 This considerably complicated the burden on the user, who had to be aware of this difference, and remember as many telephone numbers as there were terminal types° Roger Moore's multiplexor code took a different approach, which made the user's burden as light as possible. It simply assumed that the terminal type was ambiguous until the first character of the initial transmission came in. The transmission code for the right-parenthesis character was different for each terminal type that was supported (the 1050, and the EBCDIC- and correspondence-coded 2741's), so the first character had to be one of three codes. If it was none of them, the input was ignored, and a fresh input awaited. If it was one of the three possible codes, the terminal type was then known. Thus the APL system needed only one telephone number for all of its telephones. Among other things the first APL system did to keep terminal users happy, was to allow computing to go on concurrently with printing 6~ the output. Furthermore, Breed and Moore spent large amounts of time fine-tuning the terminal-handling part of the system, to give the minimum number of idles at the end of a line of type, so that the printing element was no sooner back at the left margin than typing immediately began for the next line.
    One of the most characteristic conveniences of the system is the cue chosen for the user to make a new entry. On other systems being developed at this time, this user cue varied from one kind of character sequence to another: on one system a question mark would be printed, on another, a rather long-winded time stamp, on another, the word "READY" In keeping with its general policy of informing the user as briefly as possible, the signal APL uses to indicate that output display has finished, or that comput@r processing is over, is succinct indeed. No printing characters appear at all: six spaces are sent, moving the cursor or printing element to the right, and the keyboard is unlocked for a new input. To me, that six-space cue is one of the key items in APL's elegance. Larry Breed recalls that it was Ken Iverson who suggested it.
    Extract: Conclusion
    Conclusion
    Eventually the TSS project got straightened out, so that by 1970 or so it was able to do useful work. This was after it had been shown conclusively that demand paging was a failure, given the currently available storage technology, and people were beginning to discuss the notion of "working set". It was, however, a costly experience.
    The key difference between the TSS and the APL projects, that made the great early success of APL possible, and the initial failure of TSS inevitable, was that the TSS implementers were attempting to push the technology beyond the limits of the possible, and they didn't realize this when they started. On the other hand, the APL implementers had modelled their design beforehand, and furthermore had an intelligent understanding of the limited capabilities of the equipment available to them. They managed to extract from this equipment all that it was capable of delivering, but understood that there were limits to the possible.

          in ACM Computing Reviews 19(10) October 1978 view details
  • Irons, E. T. review of Iverson 1979 view details Abstract: This article discusses the use of "operators" in programming languages, i.e., operations which apply to functions to produce functions. The first half of the paper describes the operators of APL (inner and outer product, scan, and reduction) and gives a number of examples of their use. APL experts will probably find little that is new here, although the less expert may find some surprises. The last half of the article proposes some specific ideas for handling operators in more general ways than APL now does, and suggests several new operators. As is the case with the present APL, the notions proposed are chosen with great care to be broadly useful without duplicating other APL facilities, and draw with precision and good judgment on the world of mathematics. The style is terse, but those unfamiliar with the operator concept should find the discussion enlightening (the idea really isn't used much except in APL and LISP). The APL experts may feel cheated on detail, but the references appear to fill in the gaps.

          in ACM Computing Reviews 21(02) Feb 1980 view details
  • Jones, W. T. and Kirk, S. A. "APL as a software design specification language" view details Extract: Introduction
    A proposed extension of APL as a softwzre design tool is presented. The approach of system specification using a programming language is compared to the non-programming language system PROPLAN presented by Pengilly (1975). Illustrative examples given by Pengilly are translated into the extended APL format.
    Advocating the adoption of a programming language in software design is not intended to exclude the use of natural language or other formalisms and documentation aids such as HIP0 which are commonplace in a software engineering environment. However, the importance and even necessity of specification languages which, when used in a design, can 'enhance the process of verifying correctness is increasing. This concern is further supported by the reliability that 'no programming philosophy will improve software reliability if the underlying system specifications are erroneous or have been incorrectly translated' (Belford and Taylor, 1976). Thus the selection or development of a software design language is inextricably intertwined with the specification verification problem. Falkoff (1976) has suggested the following criteria for the choice of a formal design language:
    1. It should be easy to learn its basic use.
    2. Formulations in the language should be suggestive and thought provoking.
    3. It should allow meaningful formal manipulation of both expressions and larger program segments.
    4. It should lead to the development of aesthetic criteria for judging the quality of a design.
    5. It should be convenient for documentation.
    6. It should be uncommitted to any particular technology or problem area.
    7. It should be applicable in a consistent way to systems of any foreseeable complexity.
    8. It should be executable on a machine.
    To this list we would add
    9. Lends itself to some form of specification verification technique.
    10. Desirable, although not mandatory, that the design language be useful in other contexts such as ordinary programming applications to motivate learning.

    The definition of a design specification language from the standpoint of the information systems analyst is 'a functional (non-procedural) programming language whose notation allows for quick, elegant and concise definition of the procedures used to input, store, process and output information'.
    The importance of a clean, rigorous specification to systems analysis is also becoming increasingly clear (Belford and Taylor, 1976; Liskov and Zilles, 1975). The clarity of software design must be well in hand before it can be assessed for correctness, efficiency, cost and other design constraints external to the system itself. A uniform, abstract notation is sorely needed for communication of the essentials of their design to other analysts independent of any particular implementation of the design.
    In view of the above, APL or an extension thereof as a specification language has a number of attractive features. First, APL is in widespread usage and has been implemented to varying extents on many machines. APL is also mathematically amenable, highly symbolic and expressions are easy to write without temporary storage variables as well as without bothersome loops that index on array variables. Its powerful array operators lend themselves to functional (as opposed to procedural) statements. These features provide a recognised powerful design facility which can be used in the problem formulation and early design phase of a software project. For example, the use of APL in the design stage, augmenting FORTRAN, eliminated errors in the logical formulation stage (Kolsky, 1969). The primary features contributing to its success were the mathematical consistency and the inherent explicitness of APL program statements from a mathematical point of view.
    All of the above listed criteria are met by APL. Objections to ease of learning with respect to software'design applications should also take into account the fact that APL is much more than a design tool. The skills developed in the use of this facility can be transferred to non-design applications. Criterion 8 relates to the need for machine testing of designs. A formal language capable of expressing the design of a system at various levels of detail can be used directly for simulating the system at any stage in the top-down design process. Appropriate tables can be substituted for functions not yet detailed. Thus the opportunity is provided for 'live' catalogues on interactive systems in which functional units can be displayed and executed for gaining understanding of their behaviour (Falkoff, 1976). Criterion 9 seems to be particularly important since a formal definition of the APL operators has been used to provide a base for a deductive system for informally proving assertions about APL programs (Gerhart, 1972).
    It may also, of course, be argued that APL has features which cause it to be undesirable as a software design language. An often mentioned fault is that of users taking advantage of the power of the language in the form of very complex statements or even perhaps complex single statement programs.These objections can be overcome by an extra measure of programming discipline which is required in the use of any high level language. In addition, however, the language, in its usual form, lacks the control structures that are known to enhance program design. The proposed extension of APL includes these needed features.

          in The Computer Journal 23(3) 1980 view details
  • Kupka, I. and Wilsing, N. "Conversational Languages" John Wiley, 1980 view details
          in The Computer Journal 23(3) 1980 view details
  • Allen, F. E. "The history of language processor technology in IBM" pp535-548. view details
          in IBM Journal of Research and Development, 25(5), September 1981 25th anniversary issue view details
  • Falkoff, Iverson: "A Source Book In APL"; 1981; view details
          in IBM Journal of Research and Development, 25(5), September 1981 25th anniversary issue view details
  • Hollis, IBM: "APL Programming Guide: Programming Conventions"; 1981; view details
          in IBM Journal of Research and Development, 25(5), September 1981 25th anniversary issue view details
  • Kay, Alan C. "Generic programming: APL and Smalltalk" view details
          in [ACM SIGAPL] APL Quote Quad 12(1) September 1981, Proceedings of the international conference on APL 1981, San Francisco, California, United States view details
  • Sammet, Jean E. "History of IBM's Technical Contributions to High Level Programming Languages" pp520ff view details
          in IBM Journal of Research and Development, 25(5), September 1981 25th anniversary issue view details
  • Allen, F. and Schwartz, J. review of Sammet and Lee HOPL conference end banquet excerpts view details Abstract: The ACM-SIGPLAN History of Programming Languages Conference held in Los Angeles on June 1-3, 1978, was videotaped and excerpts of the presentations are available on two tapes; these and two tapes from the banquet provide brief but penetrating glimpses of the people most involved in the development of the 13 languages covered. At the conference and in the proceedings these leading formulators of the history of programming languages describe how their language was developed -- the historical setting of the work and how and why decisions were made. The videotape excerpts provide a summary of these descriptions.

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

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

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

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

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

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

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

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

    In his summary Fred Brooks says that "the best thing about this conference is the character set." He also points out that the presentations on the languages designed by a committee emphasized the process, whereas the presentations on single-author languages emphasized technical issues. These tapes capture the factors that have made the history: the personalities, the process, and the technology. They are interesting now and will be invaluable to future historians of the pioneering period of language development.
          in ACM Computing Reviews March 1982 view details
  • Busman, R. J. review of Falkoff and Iverson 1978 view details Abstract: This paper describes major milestones in the early development of APL. The authors are Kenneth E. Iverson, the inventor, and Adin Falkoff, who used the notation early in his work in parallel search memories.

    APL grew out of a background rooted in mathematics, as most programming languages have, with an overriding concern for simplicity and practicality. APL has followed closely the concepts of mathematics without regard to machine compromises. The paper presents a personal view and the reader is advised to consult other sources, such as "The Design of APL", for further historical information. The authors encourage other contributors to APL to publish other historical facets of the language.

    The development of APL was begun in early 1956 by Iverson as a tool for describing and analyzing various topics in data processing, for use in teaching classes, and in writing a book, Automatic Data Processing, undertaken together with Frederick P. Brooks, Jr. The language was first explicitly used for communication during a leave from Harvard with the firm of McKinsey and Co. in 1957. Iverson joined IBM in 1960 and Falkoff began using it. In 1964 they began planning to implement it to enhance its utility as a design tool; implementation was completed when they were joined by Lawrence M. Breed in 1965.

    The paper focuses on the following four stages of evolution:
    1) Academic use (1957-1960)
    2) Machine description (1961- 1963)
    3) Implementation (1964-1968)
    4) Systems (after 1968)

    The academic use period (1957-1960) was important because it led to an understanding of the concept of function and the role of the representation of data, including the use of concepts from tensor analysis, such as inner and outer product, use of rank for the dimensionality of an array, and in the treatment of a scaler as an array of rank 0. Emphasis on generality and identities made the language more useful.

    In 1954 a new graduate program at Harvard in Automatic Data Processing, where Iverson was appointed, provided a stimulus in developing notation. In 1961, A Programming Language was submitted for publication. Iverson was not reappointed at Harvard because he had published nothing but one little book!

    The machine description period (1961- 1963) saw the use of APL in describing a number of computer systems, such as the IBM 360 (p. 678,37 statements). A consolidation and regularization of many aspects, such as maximum and minimum, were seen, along with increased understanding of the potential of reduction and inner and outer product. Also notable was the rigorous adoption of a right-to-left order of execution. Perhaps the most important developments were in the use of a collection of concurrent autonomous programs to describe a system, and the formalization of shared variables as a means of communication between programs.

    The implementation period (1964-1968) was entered with a confidence that the language was sufficiently well defined that it could be implemented. The first step was to define an APL character set which, as it turned out, exercised a surprising degree of influence on the development of the language. The linearization of the language (with no superscripts or subscripts), which at first seemed to present unpleasant limitations, produced beneficial changes and led to important generalization and to the recognition of the operator as a separate and important component of the language. The limitation of the character set led to the representation of both a monadic and dyadic function by the same symbol and to the important notion of composite characters by overstriking one character with another.

    Implementation led to a new class of questions, including the formal definition of functions, the localization and scope of names, and the use of tolerances in comparisons and printing output. It also led to questions concerning the environment and its management. Two early decisions were critical in the development: 1) the implementation was to be experimental with emphasis on flexibility; 2) the language was to be compromised as little as possible by machine considerations. This led Breed and P. S. Abrams to build an interpretive implementation in the summer of 1965 using TSM on a IBM 7090. In early 1966, an implementation for the System/360 was begun with work that started in earnest in July and culminated in a running system in the fall (2 1/4 people took 4 1/2 months).

    Since arrays are primitive in APL, the introduction of declarations into the language was avoided. Transitions between data types would be done automatically. The fundamental decision concerning the systems environment was the adoption of the concept of workspace. The language used to control the system functions of loading and storing workspaces was not APL, but comprised a set of system commands.

    The systems period (after 1968) begins with the use of APL by others in IBM. The implementors quickly learned the difficulties associated with changing the specifications of a system already in use and learned to appreciate the importance of a relatively long period of development that preceded the implementation. On the other hand, use of the system exposed its deficiencies. Extensions and generalizations rectified some of the deficiencies. The problem of APL's isolation from the outside world was being tackled with the introduction of a file system in 1970, and a proposed shared variable processor that would culminate in IBM's APLSV in 1973.

    In conclusion, APL is a language that is rooted in mathematical notation, employing such fundamental notions as functions, variables, and decimal representation of numbers along with arrays as primitives in the language. A view of programming languages as part of the longer-range development of mathematical notation can serve to illuminate their development.

    Earlier computer languages dropped many of the mathematical notions for practical reasons. Variable names were represented by register numbers. Even with more recent higher level languages many of the original limitations remain. APL has remained much closer to mathematical notation, emphasizing principles of simplicity and uniformity. For example, the order of execution of the conventional expression FGH(x) can be expressed by saying that the right argument of each function is the value of the entire expression to its right; this rule, extended to dyadic as well as monadic functions, is the rule used in APL.

    The evolution of APL is far from finished. In particular, large areas of mathematics, such as set theory and vector calculus, can clearly be incorporated in APL through the introduction of further operators.

    REFERENCES
    [1] FALKOFF, A. D.; AND IVERSON, K. E. The design of APL, IBM J. Res. Dev. 17 (1973), 324-334.
    [2] BROOKS, F. P.; AND IVERSON, K. E. Automatic data processing Wiley: New York, 1973.
          in ACM Computing Reviews March 1982 view details
  • Foster, Et Al: "APL Quote Quad: The Early Years"; 1982; view details
          in SigAPL: "APL82 Conference Proceedings"; 1982; view details
  • Kerner, L.O. review of Allen 1981 in ACM Computing Reviews September 1982 view details Abstract: This history of language processors in IBM can be divided quite naturally into five periods, generally delineated by the introduction of significant new products. The first period starts with the introduction of the IBM 701 in 1952 and the early "automatic-programming system" -- Speedcode -- for this computer in 1953. In 1954 the second period starts with the work on FORTRAN I, a language and system which established the foundations of compiler technology. The period from 1957, when the 709 was announced, provided many computers, languages, and systems: the 7070, 7090, 1401, COBOL, RPG, and FORMAC. In 1964 IBM announced the System/360 as a family of compatible computers. The new PL/I language had to support most of the configurations and to function in the environment supplied by the operating system. Another important language of this period was APL, implemented on the 360 in 1966. During the seventies IBM was busy with theory: program analysis and optimization, global register allocation, and implementation based on a LARL parser-generator. The reader can see the relationship between theory and practice. Much historical information is included, but of course all this is seen through the eyes of IBM. The paper contains 89 relevant references.



          in SigAPL: "APL82 Conference Proceedings"; 1982; view details
  • Smillie, K W. review of Sammet 1981 in ACM Computing Reviews September 1982 view details Abstract: This paper gives an assessment of the contributions of IBM to the development of programming languages. It begins with a very brief survey of the development of programming languages in order to place the work of IBM in perspective, followed by a few remarks on Speedcoding and PRINT, two very early attempts within IBM to develop programming languages. The four languages considered by the author to be major contributions by IBM are FORTRAN, GPSS, APL, and PL/I. The summary of the development of these languages is based primarily on the papers presented at the History of Programming Languages Conference in Los Angeles in 1978, and will be familiar to the readers of either the Preprints or the Proceedings of this conference. Several other languages -- Commercial Translator, FORMAC, SCRATCHPAD, QUIKTRAN, and CPS -- which have made important but lesser contributions are discussed briefly. A few remarks are made on IBM's contribution to the syntactic and semantic description of languages with Backus-Naur Form and the Vienna Definition Language, respectively. There is a list of 58 references.

    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 SigAPL: "APL82 Conference Proceedings"; 1982; view details
  • Steel, T. B. review of Wexelblat 1982 view details Abstract: This compendium is a magnificent book, belongs on the shelf of every information processing professional, and should be required reading for anyone who is to be granted a degree in computer science. While the book purports to be the record of the ACM SIGPLAN Conference on the History of Programming Languages held in Los Angeles in 1978, it is rather more than just that. It is an impressionist painting of a longvanished world whose inhabitants created a structure that has a profound influence, not only today but well into the foreseeable future, on the way all our institutions, commercial, governmental, or academic, conduct their affairs. The languages used to prepare computer programs dictate in many respects the thought patterns of the programmers, the questions they ask their users, the difficulty of implementing particular algorithms, and thus to a considerable extent what actually gets done. Beyond that, while it is premature to predict detailed effects, the consequences to the next generation of being taught these languages in school are certain to be enormous. The volume under review presents an account of how this structure came to be the way it is as seen through the eyes of some of the individuals responsible.

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

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

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

    ALGOL 60
    APL
    APT
    BASIC
    COBOL
    FORTRAN
    GPSS
    JOSS
    JOVIAL
    LISP
    PL/I
    SIMULA
    SNOBOL

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

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

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


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

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

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

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

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

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

    The question and answer sessions were often as interesting as the talks. The book gives John Backus's answer to the question why the letters I through N were chosen to designate integers. The readability of these sections attest to the effort which Richard Wexelblat put into the editing of this volume. The History of Languages represents a tremendous amount of effort from a great many people, and is a book which programmers as well as language designers will find both instructive and enjoyable.
          in ACM Computing Reviews March 1982 view details
  • Ny/SigAPL: "APL As A Tool Of Thought, I - V ('83-'87)"; 1983-1987; view details
          in ACM Computing Reviews March 1982 view details
  • SigAPL: "APL84 Conference Proceedings"; 1984; view details
          in ACM Computing Reviews March 1982 view details
  • Martin, James "4GL Fourth-Generation Languages Volume III, 4GLs from IBM" James Martin Englewood Cliffs, New Jersey: Prentice Hall, 1986 view details
          in ACM Computing Reviews March 1982 view details
  • SigAPL: "APL86 Conference Proceedings"; 1986; view details
          in ACM Computing Reviews March 1982 view details
  • Iverson: "A Dictionary Of APL" ACM SIGAPL APL Quote Quad 18(1) September 1987 pp5-40 view details DOI Extract: Introduction
    APL is a formal, imperative language. Because it is imperative,
    a sentence may be called an instruction, and may be
    executed to produce a result. In illustrations used here an
    instruction will be indented, and the result of its execution
    will be shown on the following line without indentation.
    Thus:
       3+4
    7
       2x(3+4)
    14
    Because it is formal and unambiguous, APL can be
    executed mechanically by a machine called a computer or,
    strictly speaking, an APL computer, or APL system. For
    this reason it is also called a programming language, a
    phrase from which its name derives. Because it shares the
    analytic properties of mathematical notation, it is also called
    an analytical programming language.
    Like any living language, APL has dialects, resulting
    in part from evolution that has rendered certain constructs
    obsolete, but also from the limitations and special characteristics
    of the many different computers on which APL
    systems are implemented. Although this introduction includes
    a brief discussion of dialects, the reader may find
    it necessary to consult manuals for specific systems, or the
    APL Standard promulgated by the International Standards
    Organization [1].
    APL originated in an attempt to provide consistent notation
    for the teaching and analysis of topics related to the
    application of computers, and developed through its application
    in a variety of topics, and through its implementation
    in computer systems. Extensive discussions of the history
    of the language may be found in The Design of APL [2]
    and The Evolution of APL [3], and in the publications cited
    therein.
    A dictionary should not be read as an introduction to
    a language, but should rather be consulted in conjunction
    with other material that uses the language in some context
    of interest to the reader. Even the general section on
    grammar, which may be intelligible even to the beginner,
    should perhaps be studied only after a certain amount of
    other exposure to the language.
    On the other hand, a dictionary should not be used only
    to find the meanings of individual words, but should also
    be studied to gain an overall view of the language. In particular,
    the grammar may be profitably reviewed again and
    again in the light of increased knowledge of the language,
    and the study of groups of related verbs and adverbs can
    reveal important relationships otherwise easily overlooked.

          in ACM Computing Reviews March 1982 view details
  • SigAPL: "APL89 Statistics Tutorial"; 1989; view details
          in ACM Computing Reviews March 1982 view details
  • IBM: "IBM Sys Resrch J'rnal, Dec '91 V30/4"; 1991; view details
          in ACM Computing Reviews March 1982 view details
  • Ny/SigAPL : "APL As A Tool Of Thought VII"; 1991; view details
          in ACM Computing Reviews March 1982 view details
  • [SigAPL] APL93 International Conference on APL "Taking a closer look" August 15-19, 1993 at Toronto, Ontario, Canada view details
          in ACM Computing Reviews March 1982 view details
  • Ny/SigAPL : "APL As A Tool Of Thought VIII"; 1993; view details
          in ACM Computing Reviews March 1982 view details
  • Ny/SigAPL : "APL As A Tool Of Thought IX"; 1994; view details
          in ACM Computing Reviews March 1982 view details
  • Vandoni, Carlo "Scientic Data Visualization" Cern December 1995 view details pdf
          in ACM Computing Reviews March 1982 view details
  • Hui, Iverson: "J Dictionary"; 1998; view details
          in ACM Computing Reviews March 1982 view details
  • Skillicorn, David B. and Talia, Domenico "Models and languages for parallel computation" pp123-169 view details
          in [ACM] ACM Computing Surveys (CSUR) 30(2) June 1998 view details
  • APL Notes view details External link: Online at Jim W's site
          in [ACM] ACM Computing Surveys (CSUR) 30(2) June 1998 view details
  • Library of Congress Subject Headings A27 view details
          in [ACM] ACM Computing Surveys (CSUR) 30(2) June 1998 view details
    Resources