RAPIDWRITE(ID:462/rap002)Simplified COBOL dialectICT UK 1962 Modified less-verbose COBOL with reduced command set, symbols, simplified function for picture. Could be translated into COBOL 61, and also into a special processor for the ICT 1301. Related languages
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: RAPIDWRITE RAPIDWRITE This is the language of I.C.T., developed initially for the 1301 but now to be also implemented on the 1500, although this machine has, of course, a COBOL compiler supplied by R.C.A. RAPIDWRITE is a subset of COBOL based chiefly on the 1960 version but with some facilities apparently introduced in anticipation of the 1961 report. Its chief merit is the reduction of writing and punching obtained by the use of pull cards for program statements, and yet the compiler produces a full COBOL listing for documentation purposes. RAPIDWRITE in its minimum form (i.e. for the smallest 1301 without magnetic tape) is likely to be the first of the advanced home-made commercial compilers that actually works. And, what is more, the compiler will itself operate on the minimum machine. in The Computer Journal 5(2) July 1962 view details in The Computer Journal 4(4) January 1962 view details in Wegner, Peter (ed.) "An Introduction to Systems Programming" proceedings of a Symposium held at the LSE 1962 (APIC Series No 2) 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: ICT RAPIDWRITE ICT RAPIDWRITE ICT made a study of COBOL in relation to its readability, its simplicity and its internationality, a study which bore fruit in RAPIDWRITE, for use with their 1301 and 1500 computers. They found COBOL easy to read, an essential feature for data processing managers and systems analysts, but also verbose and difficult for programmers to write. By cutting out about 10% of its marginal, little used, facilities and redundancies, e.g. using the verb compute to replace the four separate words for the arithmetical functions, and by transferring all the superfluous material on to pre-printed forms, thus preserving the readability whilst leaving little for the programmer to write, they reduced the essential features of COBOL to the simpler language of RAPIDWRITE. By doing this the language could be described in an 8-page manual and a training course takes 2 days only as against 10 days for a COBOL course or one month for a machine code course. The Compiler, of some 40,000 words, was expected to start making translations at the end of May 1962. Can a language be said to be universal when its readability depends on English? The ICT attempt to get over this hurdle was the only one described to the Conference. RAPIDWRITE has three features which can be prepared in any language using the 26-letter alphabet: pre-printed stationery, a format dictionary and a synonym table, the two latter being built into the computer store. By making the appropriate substitutions, a program can even be converted from one language to another. Thus it is available to non-English speaking users, a point of some importance to a manufacturer with a world-wide market. in The Computer Bulletin September 1962 view details in The Computer Bulletin September 1962 view details in Goodman, Richard (ed) "Annual Review in Automatic Programming" (3) 1963 Pergamon Press, Oxford view details The author of ICT RAPIDWRITE calls his system an "interesting contribution -- based on COBOL -- to the problems of writing coding-aids." The reason for creating a new programming system seems to be the author's belief that ease of program writing and readability by an inexperienced programmer are incompatible. The advantages of ICT RAPIDWRITE are described as "less rules, less writing, less possibilities for errors." One wonders whether this in itself justifies the effort involved in developing a new programming system. Since the idea of ICT RAPIDWRITE is full of latent possibilities to improve other shortcomings of automatic programming systems it is peculiar indeed that none of them are mentioned. The paper is neither a complete description of the language nor a primer. Only the basic principle is presented. As in COBOL, the program consists of three parts. Environment and data divisions seem to be, though this is not mentioned, identical to COBOL'S. Filling out the coding forms of the procedure division is very much like writing in an assembly language. The coding forms are printed directly on the cards into which the symbols are to be punched. There are 11 different types of cards, each of which represents a COBOL-verb. Only the various classes of COBOL-names are to be written, and they attain their meaning by position on the card, whereas connectives and other COBOL words are preprinted on the cards and, as far as the processor is concerned, implied by the card type. Short alphanumeric symbols are to be used as COBOL names. For communication and documentation purposes the translator produces a complete COBOL program as a printout only. COBOL names are inserted by means of a symbol equivalence table to be supplied by the programmer. The author states that translation "takes approximately two hours in the most extreme case." There is no other indication as to the efficiency of the system or as to whether the system has been implemented at all. in ACM Computing Reviews 4(03) May-June 1963 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 Goodman, Richard (ed) "Annual Review in Automatic Programming" (3) 1963 Pergamon Press, Oxford view details in The Computer Journal 7(2) July 1964 view details This reduction in writing by the programmer is accomplished by providing him with a rigid format in which he tells the compiler the information required in the Environment, Data, and Procedure Divisions. It should be noted here that DETAB-X does likewise for its Data Division and that the Western Data Processing Division at UCLA has implemented something similar for its COBOL programs. For its procedure division, ICT has an individual sentence fonn for each of the following COBOL verbs: read, write, go, stop, move, compute, perform, if, subscript, include. The programmer fills in only those words needed in the particular statement he wants to make. The compiler will generate the complete COBOL statement. This reviewer strongly recommends that COBOL users and equipment manufacturers providing COBOL compilers investigate this approach to COBOL. in ACM Computing Reviews 5(05) September-October 1964 view details in ACM Computing Reviews 5(06) November-December 1964 view details in ACM Computing Reviews 5(06) November-December 1964 view details in ACM Computing Reviews 5(06) November-December 1964 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 5(06) November-December 1964 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 |