CLEO(ID:318/cle004)Autocode for EE LEO computersfor Clear Language for Expressing Orders, Coding for LEO. Supposed to combine features of COBOL and Algol English Electric-Leo-Marconi (later ICL), UK 1964. Used until early 1972 on Leo III mainframes. References: The properties of data It is, of course. the available properties of the data which to a large extent determine the power of an automatic programming system, and distinguish commercial from mathematical languages. Consider the function of moving data within the internal store. In a mathematical language the problem is trivial because the unit which may be moved is very restricted, often to the contents of a single machine word. But in a commercial language this limitation is not acceptable. There, data units will occur in a variety of shapes and sizes. for example: i) Fixed Length Units (i.e. those which on each occurrence will always be of the same length) may vary widely in size and will tend not to fit comfortably into a given number of words or other physical unit of the machine. Generally the move will be performed by a simple loop. but there are some awkward points such as what to fill in the destination if the source is the smaller in size; ii) Static Variable Length Units (i.e. those whose length may vary when they are individually created but will not change subsequently) are more difficult to handle. Essentially the loop will have two controlling variables whose value will be determined at the moment of execution. There are again awkward points such as the detection of overflow in the destination (and deciding what to do when it occurs, since this will only be discovered at run time); iii) Dynamically Variable Length Units (i.e. those which expand and contract to fit the data placed in them) are even more difficult. They have all the problems of (ii), together with the need to find and allot space when they expand. It is clear, therefore, that a simple MOVE is less innocuous than it might seem at first. Actually the above remarks assumed that it was not possible to move data between different classes of units. The absence of this restriction, and the performance of editing functions during the process, can make the whole thing very complicated for the compiler indeed. The properties of data will have a similar influence on most of the other operators or verbs in the language. This has particular significance when the desired attribute is contrary to that pertaining on the actual machine. Thus arithmetic on decimal numbers having a fractional part is thoroughly unpleasant on fixed-word binary machines. Nevertheless, despite these difficulties considerable progress has been made toward giving the user the kind of data properties he requires. Unfortunately this progress has not been matched by an improvement in machine design so that few, if any, of the languages have achieved all of the following. (a) The arbitrary grouping of different classes of unit, allowing their occurrence to be optional or for the repetition in variable-length lists. (b) The input and output of arbitrary types of records, or other conglomerations of data units. having flexible formats. editing conventions and representations (c) The manipulation of individual characters, with the number and position of the characters being determined at run time. (d) The dynamic renaming or grouping of data units. Yet users do need these facilities. It is not always acknowledged that getting the main files on to the computer, before any processing is done, may constitute the largest single operation in many applications. Furthermore. these files will have a separate independent existence apart from the several programs which refer to them. Progress has also been made in declaring the data properties in such a way as to imply a number of necessary procedures to the compiler. For example, if one declares both the layout of some record to be printed, and the printed record, the compiler may deduce the necessary conversion and editing processes. It is here, in the area of input and output, that some languages have approached the aim of being problem-orientated. Extract: CLEO CLEO This is the language of LEO Computers. designed for LEO III, and is almost certainly the most recent language to be specified. It is of particular interest due to its having a combined aim toward both mathematical and business purposes. Only a preliminary report on CLEO has so far been available. but this is impressive in so far as it goes. The language might be described as being akin to both FACT and ALGOL, in that there are features of the former in the file processing and of the latter in the other procedures. in The Computer Journal 5(2) July 1962 view details Introduction Electronic computers are able to work at high speeds only because they are programmed. Analysis of a problem, or a data processing procedure, and the programming of it for a computer in machine code, is a laborious task. In the early machines, users soon appreciated the advantage of having standard programs for assembly and program development, and a library of routines for regular calculations, complex number input and output, and for tracing the course of programs during program development, particularly when unexpected results were given when the program was tried on the machine. Where jobs are to be done regularly, it is still most economical, in the long run, to program them in machine language using such library routines as may be available. But for jobs which have to be done only once, or where it is desirable to try-out part of the job first and then extend the application of the computer, simplified programming systems have been developed. By their means, the computer can be addressed in a form of English, or by direct use of mathematical symbols if these are available in the character set of the teleprinter-punch used for punching the program. These simplified programming systems to which I shall apply the term "Autocodes" (originally named by Brooker at Manchester), together with available libraries of programs, constitute a very significant extension of the machinery which is now available. Besides saving the time spent on programming, these systems reduce the clerical errors of program writing by eliminating many tedious steps and this also reduces the time taken by program development. They also make it easier for the writer (or another person) to amend the program at a later date. In the earlier systems, the simplification entailed a varying loss of operating speed, varying between two and fifteen times as long to do a job on the machine. But a half hour of computer time after a few hours' programming in autocode is a more economic proposition for a one-off job, or trial of a routine job, than several weeks on programming, followed, after several trials, by a successful five-minute run on the computer. The newer programming systems, which involve a preliminary operation to compile a machine code program, will suffer less loss of speed and will become the normal method of programming computers for calculations and dataprocessing work, where the operations are not sufficiently standard to justify the writing of specific or general programs in machine language. Extract: Work at Rothamsted Work at Rothamsted In his valedictory Presidential address to The British Computer Society in London on 26 September 1961, Dr. Frank Yates reviewed the contribution which computers have made and are making in research statistics. It is on the solution of problems involving heavy numerical computation, in pure research, and in engineering design that, in his view, computers have achieved their most striking successes: Dr. Yates went on to point out that even in fields where computational tasks had previously been performed on desk calculators, computers could introduce three new features: (a) Speed, e.g. where further progress depends on knowing results to date. (b) A more thorough job, with better editing of data and more accurate calculations. (c) Relegation of computational methodology to the machine, so that people requiring to do calculations do not have to know the detail of the calculations involved. His paper (Yates, 1962), published in the January issue of The Computer Journal, reviews experience at Rothamsted and the development there of general programs for statistical work and some autocodes at other centres. If a general purpose program is available to include a mathematical procedure or the statistical method which one needs for a piece of analysis, then more people can use the computer. 1 have prepared a schedule of some of the schemes that are now available, or may be expected to be available early in 1962. Those who have access to a computer may find this of interest to follow up whichever line of development is applicable. Extract: Applications in Metal Box Company Applications in Metal Box Company In a paper published in The Computer Journal for April 1961 (Gearing 1961) 1 referred to the use which we, in The Metal Box Company Limited, had made of Pegasus autocode. I reviewed, in some detail, two programs. One of these was an analysis of a market survey for household trays in which interviews were conducted with some 1,100 households, covering 17 general questions and 10 observations of each tray found at the house: these questionnaires were analysed and 17 tables for the internal report were printed direct from the computer output tape. The other program related to part of our work on experimental sales forecasting and is now available in the Pegasus/Sirius interchange scheme (Ferranti, 1960). Our first computer application to quality control was in 1958-59 when we undertook an analysis of variance in connection with a productive operation being camed out by a group of machines in the chain between the sheet of tinplate and the finished open top can. Three factors were involved. The autocode program for Pegasus was thought to be rather slow and a full machine code program was written by Mr. D. Bulcock and is now available in the Pegasus interchange scheme. There are other analyses of variance programs available, notably one by BISRA (Caner and Taylor, 1960) which caters for up to seven factors, but if there are more than seven levels and only three factors involved, our program permits all the levels of data to be used. Nowadays, we would not attempt to write a full machine code program unless the job was going to be frequently done and would require considerable machine time. In the group of machines which we are using, a compiler-program has become available which automatically translates the Pegasus autocode program into Sirius machine orders (Ferranti, 1959 and 1961). In 1960 we were asked to assist in the analysis of data on the variability of some raw material which had been collected from sampled consignments over two years. Several different characteristics of the material had been measured. An autocode program was wntten to analyse each characteristic separately, prmting sample means, ranges, standard dev~ations, and compiling frequency distributions of means and standard deviations. A hierarchic analysis of variance was also given at the end of each characteristic. We were asked to undertake this work on 29 March and the calculations were substantially completed on 12 Aprll. Further calculations and a correlation between two characteristics were made on 3 June and 5 October 1960. Here I would like to stress that although the program was written in autocode, which is normally advocated for one-off jobs, the program is a general one. The progress of the calculations is controlled by ten parameters and the print routine by seven more. Thus one program served for the analysis of all the different characteristics, including some that involved preliminary arithmetic on pairs of observations. The correlation program was written separately but took only two hours to write, using pairs of exlsting data tapes fed in on the two tape readers simultaneously. Extract: Scientific Autocodes Scientific Autocodes The list appended covers a wide range of programs. compilers, autocodes. Among the autocodes which can be taught in a few days and which are already fully operational are : Mercury autocode. Pegasus/Sirius autocode. Ferranti Matrix Interpretive Scheme. Deuce Alphacode. IBM Fortran. Edsac 2 Autocode. Stantec Zebra Simple Code. Elliott 803 autocode. Elliott and other systems based on ALGOL Extract: Commercial Autocodes Commercial Autocodes Those concerned with Commercial Data Processing should have a look at: ICT Rapidwrite-Cobol. Ferranti Nebula. Cleo & Gypsy when available. These may take a couple of weeks to study, because, speaking from experience with Nebula, there are not only procedure descriptions but also file outlines and specifications of format of data and results when dealing with computers having considerable ancillary equipment. The Scientific Autocodes are usually concerned with one medium of inputloutput only, punched tape or punched-cards. Programming a data processing operation in a Commercial Autocode like Nebula becomes a full-time job; but it is easier to train staff in Nebula than a machine code and the autocode compiler will (we hope) take care of housekeeping routines when opening and closing files. We are using young men and women of O level mathematics, who have had experience of controlling our punched card routines, for this work. in The Computer Bulletin March 1962 view details Aims What do we want from these Automatic Programming Languages? This is a more difficult question to answer than appears on the surface as more than one participant in the recent Conference of this title made clear. Two aims are paramount: to make the writing of computer programs easier and to bring about compatibility of use between the computers themselves. Towards the close of the Proceedings one speaker ventured that we were nowhere near achieving the second nor, indeed, if COBOL were to be extended any further, to achieving the first. These aims can be amplified. Easier writing of programs implies that they will be written in less, perhaps in much less, time, that people unskilled in the use of machine language will still be able to write programs for computers after a minimum of training, that programs will be written in a language more easily read and followed, even by those completely unversed in the computer art, such as business administrators, that even the skilled in this field will be relieved of the tedium of writing involved machine language programs, time-consuming and prone to error as this process is. Compatibility of use will permit a ready exchange of programs and applications between installations and even of programmers themselves (if this is an advantage!), for the preparation of programs will tend to be more standardised as well as simplified. Ultimately, to be complete, this compatibility implies one universal language which can be implemented for all digital computers. Extract: CLEO CLEO Some preliminary information was also given on CLEO, the language designed by LEO Computers Ltd., for use on LEO III. This, the most recent of these programming languages, is impressive in that its goal is to cover both mathematical and commercial problems, an attempt which is long overdue. It has features akin to both FACT and ALGOL. The first version of the compiler, now in the last stages of completion, is written in an intercode, using one language to write another. While it is premature to give such information the number of orders in the Compiler is expected to be about 25,000-30,000. in The Computer Bulletin September 1962 view details Purpose of paper It is sometimes contended that the main reason for developing programming languages is to enable a person not versed in computer techniques to set down the procedure he wants carried out in such a way that this can automatically be translated into a computer program. The professional training of the person who may want to do this varies enormously: he may be a scientist, a mathematician, a statistician, an actuary, an accountant, or an office manager. For some reason it has always been assumed that the only language an office manager could use is ordinary English. However this may be, one would certainly suppose that the basic need is for a simple language. Yet the published statements on most programming languages are very difficult to follow, even by people with long experience of computers; perhaps this arises from an attempt to avoid possible ambiguities which is. of course, important because the language must be precise. The aim of this paper is to express in simple terms wl;at seem to be the fundamentals of a language which is to express the procedure to be carried out for all types of applications. It seems clear that, if the attempts in Europe and elsewhere to devise a common language for computer users are to be successful, the fundamentals must be agreed first, and each feature agreed then considered in turn to decide the best way of giving effect to it. At the same time the way must be left open to expand the language as experience reveals the need for fi~rther facilities. It will be seen, therefore. that this paper is solely concerned with devising a suitable language, not with the preparation of the compiler, though naturally the language devised must be one that lends itself to translation by a compiler. Extract: Appendix: The CLEO Language - Commands Appendix: The CLEO Language 1. The types of Command. 2. Data and Result Descriptions. 3. Overlaying of Information. 1. Types of command Commands may be either imperative or conditional. Conditional commands are executed cr not according to some condition incorporated in the command after the words "IF" or "WHEN." In what follows the word "Coniniand" is used without qualification to mean a command that is either imperative or conditional. 1.1. Commands for doing calculations SET followed by "Identifier of the result = Arithmetic expression NOTE. The arithmetic expression consists of operators and operands (or functions of operands) combined together according to the rules of algebra. Matching brackets may be inserted to group terms together. The operands may be literals or identifiers of data or intermediate results. The functions may be exp, log, sin, cos, etc. The operators may be addition, subtraction, multiplication, division, exponentiation. After division, rounding off or up may be specified by "(RO)" or "(RU)" after "SET." The remainder after division may be obtained by an additional clause, following the SET command, of the form "AND Identifier = REMAINDER" 1.2. Commands for controlling the sequence of steps in procedure GO TO followed by "Procedure label" for the step to be carried out next, or, to denote a switch, by "S : P1, P2, etc." where S is an identifier which takes integer values 1 to N and where Pn denotes the procedure label for the step to be carried out next when the switch is set at n. NOTE. The procedure label may be numeric or alphanumeric. DO followed by "Subroutine label" to execute a subroutine. NOTE. The subroutine label may be numeric or alphanumeric. After the subroutine has been executed, the next step is normally to execute the command following the DO command, but a GO TO command may be obeyed within the subroutine leading to some other step outside the subroutine. In carrying out the subroutine, however, the same subroutine may not be re-entered either directly or indirectly until the execution of the subroutine has been completed. HALT followed by "PROGRAM" to terminate the program or, where it is desired to allow the console operator to choose one among several possible continuations from a particular point in the program, by "1" immediately followed by another command "GO TO PltP2. etc." where / is a reference number which is displayed to the console operator on an indicator to indicate the nature of the stoppage. The operator may then choose to continue the program with any one of the procedures P\, PI, ? ? ., Pri, . . ., PN when n is the integer set up by the operator on the controls. IF followed by "Conditional expression Imperative command" or, by "Conditional expression Imperative command ELSE Command" where some special course of action is desired if the condition is not fulfilled. NOTE. A conditional expression consists of a relationship or several relationships joined in pairs by the words ''AND"1 or "OR.'" "AND" takes precedence over "OR," but where "OR" is to take precedence brackets are needed. The relationship may consist of two arithmetical expressions separated by "?<," "!C," " = ," "!>/* "^ " "-r-" In particular one or other or both of the arithmetic expressions may be simply an identifier, and one could be a literal. Other conditions may relate to identifiers of records of input files (see under OBTAIN) Another form of conditional expression is "END File identifier" to deal with the case when the end record of a given file has been reached. FOR followed by "Identifier = Control expression Imperative command*' to cause repeated execution of an imperative command. The control expression may take one or other of the following alternative forms: (i) "A\, A2, A$, etc." to give a series of values for the identifier determined by these arithmetic expressions (ii) "/![ : A 2 '. A^ for values from A: by steps of A 2 to A $ (iii) "~A\ '. A2 UNTIL Conditional expression" for values from A\ by steps of A2 until the condition is satisfied (iv) ""A] UNTIL Conditional expression'^ for values of A} until the condition is satisfied. Any succession of control expressions are permissible consisting of (a) repetitions of one form and/or (6) different forms. NOTE. The command to be carried out may in fact be a series of commands preceded by "BEGIN" and terminated by "END." WHEN Used in conjunction with "SKIP" and "COPY" (see later). 1.3. Commands for obtaining data and presenting results OPEN INPUT followed by "Input file identifiers" to enable the procedure for checking the file headings to be provided by the compiler. OPEN OUTPUT followed by "Output file identifiers" to enable the procedure for loading the files to be provided by the compiler. CLOSE INPUT followed by or OUTPUT "File identifier" to enable the procedure for closing the files to be provided by the compiler. Eor a magnetic-tape file "NO REWIND" may follow a file identifier to indicate that the tape is not automatically to be rewound. OBTAIN followed by "Input file identifier" which is used to obtain the next record from a file which is set out in some standard format, as on magnetic-tape files, or, when it is desired to obtain the next record only if it is of a specific type, by "Record identifier" If the next record is not of the specific type no record is obtained. NOTE. In either case, if action is required only when the record is of a given type, a conditional command may follow with a condition as follows. "IF Record identifier" READ followed by "File identifier"' which is used to obtain the next record from a file where the format varies according to the application, such as on. paper tape or punched cards, or, when it is known the next record is of a specific type, by "Record identifier" which ensures the record is treated as being of this type. NOTE. In the former case a subsequent command may be made conditional on the record being of the type required. SKIP followed by "File identifier WHEN Conditional expression Command" This enables types of records on which no action is required to be skipped, and appropriate action to be taken on those where it is required. The conditional expression may be of any form, multiple or compound, including "WHEN Record identifier to ensure appropriate action when the record obtained is of the type shown, "WHEN Identifier = I" where / is a literal to ensure appropriate action when a specific record is reached. A list of "WHEN" clauses may also be used. Any type of command may be used in the "WHEN" clause, including a further "SKIP" in order to find a lower-level identifier. NOTE. Where there are more "WHEN" clauses than one, then it is understood that when any condition reached in the list is satisfied, the command corresponding to this is executed irrespective of later conditions that might be satisfied. COPY followed by "File identifier TO File identifier" Again as in the case of "SKIP" this may be followed by conditional clauses to arrange an alternative course of action when one or more conditions are satisfied. NOTE. The same arrangement of multiple -'WHEN" clauses applies. FILE followed by "Output file identifier; List of output identifiers FROM List of input and internal identifiers" which is used to assemble and record information on a file which is set out in some standard format, as for instance on magnetic-tape files. There may in fact be more than one pair of lists in which case the second and subsequent pairs are each prefaced by "AND." In order to cope with the case where an indeterminate number of items has to be filed. the command may be limited by a clause "UNTIL Conditional expression" where the condition indicates that no further items are to be filed when the condition is satisfied, e.g. if the end marker of a list of items has been reached. If it is desired that the final item when the condition is satisfied is also to be filed, the clause "UNTIL Conditional expression INCLUSIVE" is used. NOTE. The lists of identifiers may be of items, groups of items, records, etc. One identifier on the output list may be related either to one on the input or internal list or to several of these. WRITE followed by "Identifier of output file: List of identifiers FROM List of identifiers" which is used to assemble and record information on a file where the format varies according to the application, such as on paper tape or punched cards. The arrangements for this are exactly as for FILE. followed by " Identifier of printer file" List of identifiers FROM List of identifiers" which is used to assemble and print information. The arrangements for this are the same as for FILE except that a paper throw may be indicated by the insertion of " : " after the last item to be assembled for any line. MOVE followed by "List of identifiers TO List of identifiers" which is used to move information from one set of input -or internal items to an internal set. The same arrangements apply as for FILE. CLEAR followed by "Identifier." This is used in order to assign zero to numeric items and blank to alphabetical items of the identifier. in The Computer Journal 5(3) October 1962 view details in The Computer Journal 5(3) October 1962 view details in Goodman, Richard (ed) "Annual Review in Automatic Programming" (3) 1963 Pergamon Press, Oxford view details The paper contains some detailed description of the problems involved in data handling in commercial translators with emphasis on the need for more flexibility than presently available. The author, as have many before him, again questions the value of attempting to create languages "any fool can use" at the cost of efficiency and flexibility, when even these languages will not prevent the fool from having to debug his programs. On existing commercial translators, the author lists and compares briefly COBOL, FACT, COMTRAN and several English efforts which "are either not working, or not on a par with their American equivalents." The paper concludes with some not so new but nevertheless appropriate recommendations to computer manufacturers and standards committees, and the expectation of the universal acceptance of COBOL as He commercial language. in ACM Computing Reviews 4(01) January-February, 1963 view details in The Computer Journal 7(2) July 1964 view details in ACM Computing Reviews 5(06) November-December 1964 view details An introduction to compiler writing JM Forbes English Electric-Leo-Marconi Computers Ltd., Hartree House, Queensway, London. UK This paper is based on a talk given to the Birmingham branch of the B.C.S. in January 1965. It refers to problem met with in developing a translator and a compiler for LEO III computers. These have a single-address order code, ane level of store is usually recommended, and the order code is designed to handle and store data directly in any radix; decimal, binary, or a mixed radix such as sterling. Extract: Cleo LEO Computers Ltd. started the development of CLEO, which is a full-scale Autocode, in 1961. It is now being used by the majority of those English Electric-LEO-Marconi Computers Ltd. customers who have a member of the LEO range of computers. This has been a most encouraging response; more than one user has said that all his future programming will be done in CLEO and at the time of writing at least 25 of the first 30 users of LEO equipment have used CLEO to some extent. Extract: Cleo CLEO, in common with other Autocodes, has two main divisions; the procedure division and the data division. These two divisions reflect the two main problems which occupy the attention of the CLEO compiler. These two main problems are (i) to break down the procedures into their constituent parts and into computer code; (ii) to allocate addresses to identifiers and ensure these addresses are associated with the references to their identifiers in the procedures. It should be added that the compilation process from CLEO to machine code is divided into two parts: from CLEO to INTERCODE and then from INTERCODE to machine code. Extract: INTERCODE INTERCODE It is established practice among LEO users that a data-processing system will not start to process any data until that data has been thoroughly vetted. This is equally true of compilers. If a compiler does not vet its data thoroughly it is likely to get into trouble itself or even worse produce wrong object program coding without any indication that this is the case. INTERCODE is an intermediate language with upwards of 150 actions with facilities for constants and tables and an expansion factor of about 1-0 to 1-5. Once the function part of any of these 150 actions has been recognized there remains the problem of vetting the other constituent parts of the action, of which there may be up to 5. It is a further requirement of the INTERCODE system that the nature of errors detected be printed out with the instruction in the program listing. The system adopted is to divide errors into two classes—disastrous and others. Disastrous errors would stop the program running correctly and are indicated by 5 special marks in the program listing. In addition the offending entry is designated. To carry out individual tests on each of these 150 actions, or even to identify them individually and to carry out tests by subroutine, is bound to be a fairly long process. Instead a table is held, whose entries are made up of an instruction number and certain coded details, each of which comprise a number of bits, which signify what the valid field values of the instruction are. This table is held in action-number order and, in fact, one entry is held only for the highest-numbered action in a group which share common checking characteristics. An additional complication is that certain actions may have continuation lines, and this swells the number of entries. However, the total amount of space used is equivalent only to 85 instructions. The actual checking process consists of doing a "table look-up," finding the relevant checking constant and using that constant to enter a number of routines to carry out the appropriate detailed checking. This is not claimed to be some new and marvellous technique peculiar to compilers; there are many commercial data-vetting programs which use similar techniques, but what it does illustrate, is that in an area where it may be thought that particular compiler problems exist, the solution lies in an approach which could well be applied to programs in general. Extract: Conclusion Conclusion The case for automatic programming is well known; the two main disadvantages, inefficiency in the object program and the length of time it takes to compile, are probably equally well known. Unfortunately, these two disadvantages tend to pull in opposite directions. If the compilation process took longer one could have a more efficient object program. Further, compilers usually have to be written for minimal configurations. This tends to reduce the amount of store available to the compiler writer and hence the number of instructions, and this means that the number of passes must be increased. The inefficiency factor arises partly from the need to deal with situations in a general way. For example, at the entry to any routine one cannot make any assumptions about what is in any of the accumulators or modifiers or what radix is set. Therefore the compiler writer has to take precautions and perhaps insert some extra instructions, in case the correct values are not in the relevant registers. Any hand coder would probably only do this where necessary. Furthermore a compiler can make no assumptions about the likelihood or otherwise of any particular routine of a program being obeyed. To a compiler they are all one. And it is probably because of this that compilers for machines with two levels of storage have tended to be less efficient than others. in The Computer Journal 8(2) July, 1965 view details "If attempts . . . to devise a common language for computer users are to be successful, the fundamentals must be agreed on first," we are warned. The fundamentals that are esteemed here are simplicity (for learning and using), conciseness, naturalness and precision. The author has attempted to embody these attributes in CLEO, which he proposes, at least by inference, as a rival for COBOL. The appended description of CLEO contains a list of commands and an outline of how data and results are to be described. Although it is not sufficient to support a value judgment, it appears that the goals mentioned above have not been offered as mere attention-getter but have been taken quite seriously. One hopes that these qualities can be preserved as the work of writing a compiler for CLEO, now getting under way, produces its crop of competing desiderata. in ACM Computing Reviews 5(04) July-August 1964 view details in ACM Computing Reviews 5(04) July-August 1964 view details After this opening sentence, the author goes on to give us the reasons for this fact. Briefly, these are the well-known British reserve and suspicion of anything new, the fact that automatic coding spread from America, the inefficiencies of automatic coding, and scepticism about both the possibility of, and the need for compatibility. Automatic coding languages for commercial uses exist, in fact too many of them. It seems reasonable to assume that this proliferation of languages hinders general adoption of any of them. The author describes several languages, CLEO, TALK, NEBULA, and ACL. It still looks likely that COBOL, to be implemented on ICT's 1900 series, does have a future. Compile speeds of some of the described languages are pitiful. NEBULA for ICT's Orion series, with a 75 man-year investment in programming, compiles at 3 to 4 statements per minute on an 8K machine with 32K word drum and 5 tapes. CAMEO, one LEOIII and 326, goes at 100 lines a minute; TALK on English Electric's KDF9, at 50 lines a minute, while 1900 COMPACT COBOL on the two-microsecond 1900 compiles at 125 to 150 lines a minute. A measure of the efficiency of the NEBULA object code is the statement ". . . one user'states that he can now complete in three days (with magnetic tape) sorting and tabulating routines for an extensive monthly sales analysis which previously occupied three sorters and tabulators with summary punches for the greater part of three weeks." in ACM Computing Reviews 7(02) March-April 1966 view details [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 ACM Computing Reviews 7(02) March-April 1966 view details in Computers & Automation 21(6B), 30 Aug 1972 view details The exact number of all the programming languages still in use, and those which are no longer used, is unknown. Zemanek calls the abundance of programming languages and their many dialects a "language Babel". When a new programming language is developed, only its name is known at first and it takes a while before publications about it appear. For some languages, the only relevant literature stays inside the individual companies; some are reported on in papers and magazines; and only a few, such as ALGOL, BASIC, COBOL, FORTRAN, and PL/1, become known to a wider public through various text- and handbooks. The situation surrounding the application of these languages in many computer centers is a similar one. There are differing opinions on the concept "programming languages". What is called a programming language by some may be termed a program, a processor, or a generator by others. Since there are no sharp borderlines in the field of programming languages, works were considered here which deal with machine languages, assemblers, autocoders, syntax and compilers, processors and generators, as well as with general higher programming languages. The bibliography contains some 2,700 titles of books, magazines and essays for around 300 programming languages. However, as shown by the "Overview of Existing Programming Languages", there are more than 300 such languages. The "Overview" lists a total of 676 programming languages, but this is certainly incomplete. One author ' has already announced the "next 700 programming languages"; it is to be hoped the many users may be spared such a great variety for reasons of compatibility. The graphic representations (illustrations 1 & 2) show the development and proportion of the most widely-used programming languages, as measured by the number of publications listed here and by the number of computer manufacturers and software firms who have implemented the language in question. The illustrations show FORTRAN to be in the lead at the present time. PL/1 is advancing rapidly, although PL/1 compilers are not yet seen very often outside of IBM. Some experts believe PL/1 will replace even the widely-used languages such as FORTRAN, COBOL, and ALGOL.4) If this does occur, it will surely take some time - as shown by the chronological diagram (illustration 2) . It would be desirable from the user's point of view to reduce this language confusion down to the most advantageous languages. Those languages still maintained should incorporate the special facets and advantages of the otherwise superfluous languages. Obviously such demands are not in the interests of computer production firms, especially when one considers that a FORTRAN program can be executed on nearly all third-generation computers. The titles in this bibliography are organized alphabetically according to programming language, and within a language chronologically and again alphabetically within a given year. Preceding the first programming language in the alphabet, literature is listed on several languages, as are general papers on programming languages and on the theory of formal languages (AAA). As far as possible, the most of titles are based on autopsy. However, the bibliographical description of sone titles will not satisfy bibliography-documentation demands, since they are based on inaccurate information in various sources. Translation titles whose original titles could not be found through bibliographical research were not included. ' In view of the fact that nany libraries do not have the quoted papers, all magazine essays should have been listed with the volume, the year, issue number and the complete number of pages (e.g. pp. 721-783), so that interlibrary loans could take place with fast reader service. Unfortunately, these data were not always found. It is hoped that this bibliography will help the electronic data processing expert, and those who wish to select the appropriate programming language from the many available, to find a way through the language Babel. We wish to offer special thanks to Mr. Klaus G. Saur and the staff of Verlag Dokumentation for their publishing work. Graz / Austria, May, 1973 in Computers & Automation 21(6B), 30 Aug 1972 view details Resources
|