FORTRANSIT(ID:407/for068)
FORTRAN Internal Translator
for FORTRAN Internal Translator
Subset of FORTRAN translated into IT on the IBM 650.
Bob Bemer IBM 1956
From Bemer's webpage:
"I say manpower, although the name FORTRANSIT was created by Florence (Flo) Pessin, in a conversation I had with her. I had always liked puns in creating programming names (CODASYL was my play on the legal term "codicil", but COBOL was not). Flo liked anagrams and acrostics. We agreed that it meant either 1) FORTRAN-S(oap)-IT, or 2) FOR TRANSIT(ion), or 3) FORTRAN's IT (in the verb sense of FORTRANning the IT Compiler)"
Bemer also indicates that this is very probably the first stack implementation, and that it was the work of Florence Pessin. (Predating the Samuelson and Bauer compiler by 2 years)
People: Hardware:
- IBM 650 IBM
Related languages
| FORTRAN | => | FORTRANSIT | Subset | |
| IT 2 | => | FORTRANSIT | Target language for |
Samples:
References:
Let me elaborate these points with examples. UNICODE is expected to require about fifteen man-years. Most modern assembly systems must take from six to ten man-years. SCAT expects to absorb twelve people for most of a year. The initial writing of the 704 FORTRAN required about twenty-five man-years. Split among many different machines, IBM's Applied Programming Department has over a hundred and twenty programmers. Sperry Rand probably has more than this, and for utility and automatic coding systems only! Add to these the number of customer programmers also engaged in writing similar systems, and you will see that the total is overwhelming.
Perhaps five to six man-years are being expended to write the Alodel 2 FORTRAN for the 704, trimming bugs and getting better documentation for incorporation into the even larger supervisory systems of various installations. If available, more could undoubtedly be expended to bring the original system up to the limit of what we can now conceive. Maintenance is a very sizable portion of the entire effort going into a system.
Certainly, all of us have a few skeletons in the closet when it comes to adapting old systems to new machines. Hardly anything more than the flow charts is reusable in writing 709 FORTRAN; changes in the characteristics of instructions, and tricky coding, have done for the rest. This is true of every effort I am familiar with, not just IBM's.
What am I leading up to? Simply that the day of diverse development of automatic coding systems is either out or, if not, should be. The list of systems collected here illustrates a vast amount of duplication and incomplete conception. A computer manufacturer should produce both the product and the means to use the product, but this should be done with the full co-operation of responsible users. There is a gratifying trend toward such unification in such organizations as SHARE, USE, GUIDE, DUO, etc. The PACT group was a shining example in its day. Many other coding systems, such as FLAIR, PRINT, FORTRAN, and USE, have been done as the result of partial co-operation. FORTRAN for the 705 seems to me to be an ideally balanced project, the burden being carried equally by IBM and its customers.
Finally, let me make a recommendation to all computer installations. There seems to be a reasonably sharp distinction between people who program and use computers as a tool and those who are programmers and live to make things easy for the other people. If you have the latter at your installation, do not waste them on production and do not waste them on a private effort in automatic coding in a day when that type of project is so complex. Offer them in a cooperative venture with your manufacturer (they still remain your employees) and give him the benefit of the practical experience in your problems. You will get your investment back many times over in ease of programming and the guarantee that your problems have been considered.
Extract: IT, FORTRANSIT, SAP, SOAP, SOHIO
The IT language is also showing up in future plans for many different computers. Case Institute, having just completed an intermediate symbolic assembly to accept IT output, is starting to write an IT processor for UNIVAC. This is expected to be working by late summer of 1958. One of the original programmers at Carnegie Tech spent the last summer at Ramo-Wooldridge to write IT for the 1103A. This project is complete except for input-output and may be expected to be operational by December, 1957. IT is also being done for the IBM 705-1, 2 by Standard Oil of Ohio, with no expected completion date known yet. It is interesting to note that Sohio is also participating in the 705 FORTRAN effort and will undoubtedly serve as the basic source of FORTRAN-to- IT-to-FORTRAN translational information. A graduate student at the University of Michigan is producing SAP output for IT (rather than SOAP) so that IT will run on the 704; this, however, is only for experience; it would be much more profitable to write a pre-processor from IT to FORTRAN (the reverse of FOR TRANSIT) and utilize the power of FORTRAN for free.
in "Proceedings of the Fourth Annual Computer Applications Symposium" , Armour Research Foundation, Illinois Institute of Technology, Chicago, Illinois 1957 view details
in "Proceedings of the Fourth Annual Computer Applications Symposium" , Armour Research Foundation, Illinois Institute of Technology, Chicago, Illinois 1957 view details
The FOR TRANSIT (sic) system consists of three major parts:
The translator, FOR TRANSIT, which accepts FORTRAN statements and produces corresponding IT statements.
The compiler, a modification of IT, which accepts IT statements and compiles 650 instructions in symbolic (SOAP II) language.
The assembler, a modified version of SOAP II, which produces an optimized machine language program from the symbolic instructions. Extract: The team
IBM's applied programming people worked closely with the "Computation Center" at Carnegie Institute of Technology with a view to developing a "processor" for these source statements. Priority was placed on time. We urgently wanted to have the 650 in a position to be able to accept FORTRAN statements and write object programs. As there already existed a compiler and an associated assembler for the 650, the decision was made to adapt and extend this system of existing programs and get into production.... It was immediately apparent that the language as it stood was in no way tied to the 704. All that was necessary was to write new processors for other machines and we would have a compatible language. Work started directly on both 650 and 705 processors
in Proc. Canadian Conf. for Computing and Data Processing, Jun 9-10 1958 view details
We had full intentions of using the IT language for our input to the Univac, as Mr. Bemer reported here last year, then changed our minds and decided that we needed something with "name" variables similar to Fortran or AT-3 (Mathmatic).
We also desire to use a language that will be usable on both the Univac and the 650 without too much changing-around of the pseudo-code. This desire is motivated largely by both the presence of the two machines as well as by the very nature of our main activity, namely, educational work. The advantages of a common language (or, more properly, a compatible language) are quite clear but not easily attained on two machines of such different capacities.
At the present time we are planning to use a multistage process in translating from the pseudo-code (problem-oriented language) to the machine language.
It is likely that we will process the original pseudo-code into a simpler pseudo-code, then translate that code, etc., according to the following list:
POL
POL1
SML
Preprocessor
Unisap
C-10
POL will be an algebraic problem-oriented language which will be quite rich in its abilities (possibly including such things as general summation notation, matrix manipulation, "find maximum," "find minimum," differentiation, integration, etc.). The POLl will be another algebraic problem-oriented language with about the same capabilities as presently found in AT-3 (Math-matic) or Fortran. SML is Simple Machine Language and is a language which has the characteristics of a computer but no reference at all to any particular computer. We have already completed the specifications of SML and how it is to work. Following SML will come a "preprocessor," so named because it was invented for the very purpose of preceding Unisap before its utility in this particular connection was evident.
The preprocessor is currently being debugged. The coding for SML to preprocessor is now being written. Unisap has already been mentioned as an excellent example of a symbolic assembly program and has been widely distributed. C-10 neither needs any explanation (it is the Univac machine language) nor does it particularly deserve explanation.
Extract: SOAP, CASE SOAP
I shall now descend from my blue-sky position and describe what we have already finished doing in the automatic programming business. We, as have several others, started our first efforts at automatic programming after taking a long close look at Dr. Perlis' IT compiler for the IBM 650. As usual, when one examines something created elsewhere, we thought that we could make some improvements in the existing scheme without giving up any of the advantages that were already present. Our first effort was then to write a program named "Compiler II-SOAP II." This program worked very well, turned out nice "tight" coding, and included IT as a subset language. The bulk of the flow charting, planning, and coding for Compiler II-SOAP II was done by two of my undergraduate students, Mr. Lynch, a sophomore, and Mr. Knuth, a freshman.
0ne of the more unpleasant experiences encountered in the work on the compiler was the discovery that SOAP II was unable to assemble the entire compiler owing to the symbol table becoming filled up at an early stage of the assembly process. The solution to the problem was obvious but not very satisfactory.
As a matter of fact we did modify SOAP II to dump the symbol table and then reload it again in modified form, but we abandoned this philosophy as not being a worthwhile solution to the problem. Therefore, Mr. Knuth suggested that he write a new symbolic assembly program with some new features incorporated in it. Accordingly, SOAP III (later renamed CASE-SOAP III due to some rather peculiar complaints from a large corporation) was written. CASE-SOAP-III solved the symbol-table difficulty by introducing a fairly new idea--the program point. Program points are addresses which the programmer needs to introduce in order to cause the machine to function properly but which have no mnemonic value to the functioning of the program. For example, one may frequently encounter the use of addresses such as NEXT and NXT, etc., which are included solely to link the program together but which have no significance at all in the logical structure of the problem. The program point was introduced just to solve the problem of naming these "random" addresses. The program point uses no room at all in the symbol table and is continuously redefinable by the simple expedient of using the same point over again. As an example consider the following segment of coding:
RAU ROO02
BMI 1F
STL PO005
RSL ONE6 1F
1 ALO PCON
In both cases of the use of "1F" in the instruction address position, the meaning is to use the address of program point ''1" forward. Now look at the next example (which, by the way, does nothing) :
2 RAU ROO01 1F
1 SUP ONES
NZE 1F 2B
1 RAL 6 1B
Note that the use of "1F" still refers to the forward program point, while "1B" refers to the correspondingly numbered backward program point. The use of "6" in the data address of the last instruction refers to the address of that particular line of coding (i.e., the line "1 RAL 6 1B"). Using CASE-SOAP III to write our next compiler revealed that there was an economy of approximately 50 per cent in the number of symbols used in CASE-SOAP III over the equivalent program written in SOAP II. Since we are looking forward to acquiring some day some of the optional attachments for our 650, Mr. Knuth incorporated additional pseudo-operations into CASE-SOAP III which allow one to effectively write programs for the augmented machine.
The new compiler referred to in the previous paragraph has been named RUNCIBLE. I shall now stick out my neck and state quite flatly that I do not believe that any tighter program will ever be devised for the 650. RUNCIBLE is again an algebraic problem-oriented compiler for the 650. The input language includes both IT and Compiler II-SOAP II as proper subset languages. The compiler is in a single deck of cards but exists logically in twenty-four different versions. The various versions are selected at read-in time by the storage-entry switch settings. The various possibilities are given from examining the following:
(Multipass OR One-pass) AND (650 OR 653) AND (Minimum Clocking OR
Full Clocking OR No Clocking) AND (Normal Output OR Error Search)
= (Operating Mode)
We now examine in some detail the options appearing in the foregoing equation. The multipass mode of operation is the one usually associated with 650 compilers (i.e., an intermediate language step is used). In the case at hand, the intermediate language is CASE-SOAP III. The one-pass mode turns out a machine-language program directly in a five instruction per card format. In the second option the term 650 refers to the basic 2,000-word 650 as being used as the object machine (i.e., the machine on which the compiled problem is to be run), the term 653 means that the compiled program is to be run on a machine equipped with floating point, index registers, and (at the programmer's option) core storage. It is also possible to cause the output machine language to be tailored to fit a machine equipped with core storage only and neither index registers nor floating point. The various "clocking" options mentioned refer to the several "tracing" modes that can be called upon to help debug the object program. It is possible to ascertain (while actually operating the object program) upon which statement in the pseudolanguage the machine is working. This one feature is proving to be one of the most helpful debugging aids that we have ever encountered.
Extract: IT, Runcible
The input language to RUNCIBLE is an augmented version of Compiler II-SOAP II which includes names of subroutines and some other English-language options in the control words. A sample program which appears on page 20 of the manual follows :
The program reads in a non-negative value (and tests to see that it is non-negative) of I1 and then calculates I1 factorial and punches both the input number and the factorial value.
We are now naturally looking forward to the day when we shall have to consider a 650 compiler for the machine with tapes and RAMAC unit.
In conclusion let me state that in our opinion the most important thing to worry about, as far as application of machines to scientific and engineering problems is concerned, is the time consumed from the statement of the problem in English to the presentation of the numerical answer to the problem proposer.
We see no reason why the time consumed on the computer should be the only time interval which comes under close scrutiny. It seems much more reasonable to conserve the time of the scientist and engineer rather than the machine-after all, one may obtain machines by the simple expedient of ordering them from the manufacturer, but a foolproof, economic method of obtaining competent personnel is as yet an almost unsolved problem.
Extract: MATH-MATIC vs. RUNCIBLE
M. O. LOCKS (Remington Rand Univac) :
Could you give me your interpretation of the difference between an assembly system and a compiler system? Also, could you explain how something which is as flexible as a compiler can be gotten onto a 2,000-word drum with no further erasable storage?
MR. WAY:
Our view of an assembly system is a facility whereby one writes a program in some language-usually similar to machine language-and gets out an essentially one-to-one translation of that language. In our case we write in a symbolic language, using pseudo-codes and symbolic addresses, and get out a machine-language code along with the actual locations-in the case of the Univac I, for instance, C-10 operation codes and addresses-when we assemble the tape which will run the problem. A compiler, on the other hand, is usually a one-to-many translator. You put in, usually, algrebraic statements of your problem and get out a machine code to do the problem; the latter, of course, in appearance bears no resemblance whatsoever to the original problem statement.
Now your question about how we do this on a 2,000-word drum is of interest. A number of people said it could not be done, but Perlis proved that this was wrong. I notice that you are with Remington Rand Univac, so I see why the question comes up! If anybody ever writes a compiler that will fit inside the 1,000- word memory of the Univac I, I would ce~tainly like to see it. The whole philosophy of compiling is dictated by the machine available to do it. In the case of the Univac I, with ten tape units, one can spin wheels and do nearly anything if he has time. As examples, witness Math-matic and Flow-matic, which do spin wheels and take time, but do compile. With the 650 one does not use this type of philosophy, mainly because he cannot. So, one uses a different method of generating the machine language. I realize I haven't told you in detai! how to write a compiler; I didn't intend to. Does that answer your question?
MR. LOCKS:
Yes, that does basically answer the question, but I would like to inquire how much your 650 compiler can do as compared to a compiler which does spin wheels, Math-matic, for instance.
MR. WAY:
I am sure we can run rings around it with this 650 compiler, the basic reason being that the 650 storage of 2,000 words allows us to get more in the main Current Developments in Computer Pvogremming Techniques 131 storage of the machine at once. In our view the Math-matic system at present is rather handicapped by the input-output of the Univac I. The man who writes pseudo-code in Math-matic must know a lot about the Univac I, or he will not be able successfully to segment a problem. At least this has been our experience. Extract: FORTRANSIT, IT, RUNCIBLE
R. B. WISE (Armour Research Foundation) :
You mentioned that you were going to bypass the Perlis language compiler for the Univac I and write something more ambitious. Will this allow for IT compiler input?
MR. WAY:
We haven't decided as yet, but we would like to allow it if possible.
MR. WISE:
I, for one, would want to register a small protest if you do not. The IT language is about the closest thing we have today to the universal language among computers, and it seems to me that it would be very much worthwhile to have something-even something which some people may classify as mediocrewhich will allow communication among computers. This has been written for the 650; through the use of For Transit, you have access to some programs for the 704; it has been written for the 1103A; and, in somewhat modified form, it also fits in the Datatron 205. I think there is a big argument for allowing that type of input.
MR. WAY:
YOU opened a loophole when you said "in somewhat modified form." When I said before that our compiler would accept previous programs, I meant without any alteration.
in Proceedings of the 1958 Computer Applications Symposium, Armour Research Foundation, Illinois Institute of Technology, Chicago, Illinois view details
Shortly after FORTRAN was made available on the 650 in the form of FORTRANSIT, we ran seminars on it. I t was felt that the high mnemonic value of the FORTRAN language would be a further aid to programming. This turned out to be the case for those students or faculty members who were already familiar with the Bell System or with machine language. However, it appeared to us that those without some previous computer background did not take to the FORTRANSIT compiler system as well as they did to the Bell General Purpose Interpretive System. Students with the appropriate background and with more complex problems were pleased with the ease with which they could program their problems using FORTRANSIT.
It was about this stage that we decided that we would try to make the FORTRAN system available on our 1101. Also about this time the ElectroData Division of Burroughs Corporation indicated that they planned to make the FORTRAN system available on their forthcoming 220. Thus we felt that, by writing FORTRAN for the 1101, we would be able to program a problem in the FORTRAN language and run it on any one of our three machines. In this manner we would then be able to equalize the load on our three machines. Consequently, a year ago this past summer two of our programmers started writing FORTRAN for the 1101. They continued this work until they attended the seminar on compilers held last February 18-20, 1959, at Carnegie Institute of Technology, which was jointly sponsored by Carnegie, Case, and the University of Michigan. After returning from this seminar, these two boys reviewed their work and the compiler systems presented at this conference. They then recommended that the course of their work be changed from making FORTRAN available to making the RUNCIBLE system available for the three computers. As most of you probably know, the RUNCIBLE system of Case is the result of several revisions of Dr. A. J. Perlis' IT system. Our boys felt that RUNCIBLE was logically far more complete and much more flexible in its use. It was felt that these two major advantages were sufficiently great to overcome the loss of higher mnemonic value of FORTRAN. It was thus decided that the RUNCIBLE system would be used instead of the FORTRAN system. Since RUNCIBLE is more complete logically, it would be a relatively easy task to put a translator in front of RUNCIBLE to be able to handle the FORTRAN language if it was later decided that this was desirable.
Our decision to adopt RUNCIBLE rather than FORTRAN has been further justified by the fact that the ElectroData people appeared to have set aside their project to write FORTRAN for the 220. In the meantime, our programmers have also been able to run the RUNCIBLE on the 220 by use of the 650 Simulator. The simulator was written by the ElectroData people for the 220 and appears to be very efficient in the cases where we have employed it. It is true that this is not an exceedingly efficient use of the 220, but it is also true that in our case we will probably not run many compiler programs on the 220. It currently appears that we have enough people willing and able to write the machine language to keep the 220 busy. Even though we only installed the 220 early this year, we are already running two shifts on it. Most of this work is either sponsored research work or faculty-graduate student research projects that require the larger machine. Essentially, no one-shot small problems have been put on the 220.
We are currently running our third seminar on the RUNCIBLE system. The attendance at these seminars has varied. This quarter our Bell seminar drew the usual sixty people, and the RUNCIBLE seminar only seven. However, the two previous RUNCIBLE seminars had about twenty each. In order that we may not be accused of being out of date relative to the current push on compilers, we are considering the possibility of offering only the RUNCIBLE seminar next quarter. Perhaps this will help overcome the mass momentum that has developed relative to the Bell System. I still have, however, the strong feeling in my own mind that, for the smaller one-shot computer projects of the uninitiated, the actual time elapsed between problem initiation and problem solution may be considerably less in using the Bell System. I had the experience of sitting down with a sharp faculty person one afternoon and describing the Bell System to him. The next day he came back with a moderately complex integration problem completely programmed and ran it on the 650. I have not had the exact set of circumstances to try the RUNCIBLE system, but I doubt that the same degree of success could be achieved.
It seems very clear to me that an undisputed value for a compiler system such as RUNCIBLE or FORTRAN is for the larger-scale problems and for experimental mathematical studies, where the model is sufficiently changed to make it unfeasible efficiently to employ a simple interpretive scheme. My current feeling is that, within an educational research situation such as ours, there will always be a place for interpretive systems such as the Bell System. I t seems to me that, in learning such a system, one gets a better feeling for the way in which the machine actually functions. After all, the interpretive schemes are not too far removed from machine-language programming and yet still have many advantages over such programming. It appears that, the wider the basic knowledge that a student has, the more useful he will be when he goes out into industry, even though there his computer work may be confined to the use of a compiler. I would also concur in the continued inclusion of machine-language programming in the basic programming courses offered for credit by the Mathematics Department, the Electrical Engineering Department, or whatever department happens to offer these courses, someone has to have a sufficiently strong background to be able to build compilers.
Extract: Not using assemblers (SOAP, STAR)
You probably have noted by now that I have made no direct mention of assembly routines. This lack of reference reflects our situation at Georgia Tech. Small use has been made of them. No seminars have been run on their use. A few people have used SOAP on the 650. A very few are using STAR I on the 220. An assembly program was written for our 1101, but it was purely for intermediate purposes and had no direct use. I currently see no necessity of ever running a non-credit seminar on assembly routines, but I would advocate their inclusion in the credit courses in programming.
in Proceedings of the 1959 Computer Applications Symposium, Armour Research Foundation, Illinois Institute of Technology, Chicago, Ill., Oct. 29, 1959 view details
in E. M. Crabbe, S. Ramo, and D. E. Wooldridge (eds.) "Handbook of Automation, Computation, and Control," John Wiley & Sons, Inc., New York, 1959. view details
in E. M. Crabbe, S. Ramo, and D. E. Wooldridge (eds.) "Handbook of Automation, Computation, and Control," John Wiley & Sons, Inc., New York, 1959. view details
in ACM Computing Reviews 4(06) November-December 1963 view details
The major competitor to the 650 among the early magnetic drum computers was the Datatron 205, which eventually became a Burroughs product. It featured a 4000 word magnetic drum storage plus a small 80 word fast access memory in high speed loops on the drum. Efficient programs had to make very frequent use of block transfer instructions, moving both data and programs to high speed storage A number of interpretive and assembly system were built to provide programmed floating point instructions and some measure of automatic use of the high speed loops. The eventual introduction of floating point hardware removed one of the principal advantages of most of these systems. The Datatron was the first commercial system to provide an index register and automatic relocation of subroutines, features provided by programming systems on other computers. For these reasons among others the use of machine code programming persisted through most of the productive lifetime of the Datatron 205.
One of the first Datatron computers was installed at Purdue University. One of the first Algebraic compilers was designed for the Datatron by a group at Purdue headed by Dr. Al Perils. This is another example of a compiler effort based on a firm belief that programming should be done in problem-oriented languages, even if the computer immediately available may not lend itself too well to the use of such languages. A big problem in the early Datatron systems was the complete lack of alphanumeric input. The computer would recognize pairs of numbers as representing characters for printing on the Flexowriter, but there was no way to produce the same pair of numbers by a single key stroke on any input preparation device. Until the much later development of new input-output devices, the input to the Purdue compiler was prepared by manually transcribing the source language into pairs of numbers.
When Dr. Perils moved to Carnegie Tech the same compiler was written for the 650, and was named IT. IT made use of the alphanumeric card input of the 650, and translated from a simplified algebraic language into SOAP language as output. IT and languages derived from it became quite popular on the 650, and on other computers, and have had great influence on the later development of programming languages. A language Fortransit provided translation from a subset of Fortran into IT, whence a program would be translated into SOAP, and after two or more passes through SOAP it would finally emerge as a machine language program. The language would probably have been more popular if its translation were not such an involved and time-consuming process. Eventually other, more direct translators were built that avoided many of the intermediate passes.
in [AFIPS JCC 25] Proceedings of the 1964 Spring Joint Computer Conference SJCC 1964 view details
The family tree of programming languages, like those of humans, is quite different from the tree with leaves from which the name derives.
That is, branches grow together as well as divide, and can even join with branches from other trees. Similarly, the really vital requirements for mating are few. PL/I is an offspring of a type long awaited; that is, a deliberate result of the marriage between scientific and commercial languages.
The schism between these two facets of computing has been a persistent one. It has prevailed longer in software than in hardware, although even here the joining was difficult. For example, the CPC (card-programmed calculator) was provided either with a general purpose floating point arithmetic board or with a board wired specifically to do a (usually) commercial operation. The decimal 650 was partitioned to be either a scientific or commercial installation; very few were mixed. A machine at Lockheed Missiles and Space Company, number 3, was the first to be obtained for scientific work. Again, the methods of use for scientific work were then completely different from those for commercial work, as the proliferation of interpretive languages showed.
Some IBM personnel attempted to heal this breach in 1957. Dr. Charles DeCarlo set up opposing benchmark teams to champion the 704 and 705, possibly to find out whether a binary or decimal machine was more suited to mixed scientific and commercial work. The winner led to the 709, which was then touted for both fields in the advertisements, although the scales might have tipped the other way if personnel assigned to the data processing side had not exposed the file structure tricks which gave the 705 the first edge. Similarly fitted, the 704 pulled ahead.
It could be useful to delineate the gross structure of this family tree for programming languages, limited to those for compilers (as opposed to interpreters, for example).
On the scientific side, the major chronology for operational dates goes like this:
1951, 52 Rutishauser language for the Zuse Z4 computer
1952 A0 compiler for Univac I (not fully formula)
1953 A2 compiler to replace A0
1954 Release of Laning and Zierler algebraic compiler for Whirlwind
1957 Fortran I (704)
1957 Fortransit (650)
1957 AT3 compiler for Univac II (later called Math-Matic)
1958 Fortran II (704)
1959 Fortran II (709)
A fuller chronology is given in the Communications of the ACM, 1963 May, 94-99.
IBM personnel worked in two directions: one to deriving Fortran II, with its ability to call previously compiled subroutines, the other to Xtran in order to generalize the structure and remove restrictions. This and other work led to Algol 58 and Algol 60. Algol X will probably metamorphose into Algol 68 in the early part of that year, and Algol Y stands in the wings. Meanwhile Fortran II turned into Fortran IV in 1962, with some regularizing of features and additions, such as Boolean arithmetic.
The corresponding chronology for the commercial side is:
1956 B-0, counterpart of A-0 and A-2, growing into
1958 Flowmatic
1960 AIMACO, Air Material Command version of Flowmatic
1960 Commercial Translator
1961 Fact
Originally, I wanted Commercial Translator to contain set operators as the primary verbs (match, delete, merge, copy, first occurrence of, etc.), but it was too much for that time. Bosak at SDC is now making a similar development. So we listened to Roy Goldfinger and settled for a language of the Flowmatic type. Dr. Hopper had introduced the concept of data division; we added environment division and logical multipliers, among other things, and also made an unsuccessful attempt to free the language of limitations due to the 80-column card.
As the computer world knows, this work led to the CODASYL committee and Cobol, the first version of which was supposed to be done by the Short Range Committee by 1959 September. There the matter stood, with two different and widely used languages, although they had many functions in common, such as arithmetic. Both underwent extensive standardization processes. Many arguments raged, and the proponents of "add A to B giving C" met head on with those favoring "C = A + B". Many on the Chautauqua computer circuit of that time made a good living out of just this, trivial though it is.
Many people predicted and hoped for a merger of such languages, but it seemed a long time in coming. PL/I was actually more an outgrowth of Fortran, via SHARE, the IBM user group historically aligned to scientific computing. The first name applied was in fact Fortran VI, following 10 major changes proposed for Fortran IV.
It started with a joint meeting on Programming Objectives on 1963 July 1, 2, attended by IBM and SHARE Representatives. Datamation magazine has told the story very well. The first description was that of D. D. McCracken in the 1964 July issue, recounting how IBM and SHARE had agreed to a joint development at SHARE XXII in 1963 September. A so-called "3 x 3" committee (really the SHARE Advanced Language Development Committee) was formed of 3 users and 3 IBMers. McCracken claimed that, although not previously associated with language developments, they had many years of application and compiler-writing experience, I recall that one of them couldn't tell me from a Spanish-speaking citizen at the Tijuana bullring.
Developments were apparently kept under wraps. The first external report was released on 1964 March 1. The first mention occurs in the SHARE Secretary Distribution of 1964 April 15. Datamation reported for that month:
"That new programming language which came out of a six-man IBM/ SHARE committee and announced at the recent SHARE meeting seems to have been less than a resounding success. Called variously 'Sundial' (changes every minute), Foalbol (combines Fortran, Algol and Cobol), Fortran VI, the new language is said to contain everything but the kitchen sink... is supposed to solve the problems of scientific, business, command and control users... you name it. It was probably developed as the language for IBM's new product line.
"One reviewer described it as 'a professional programmer's language developed by people who haven't seen an applied program for five years. I'd love to use it, but I run an open shop. Several hundred jobs a day keep me from being too academic. 'The language was described as too far from Fortran IV to be teachable, too close to be new. Evidently sharing some of these doubts, SHARE reportedly sent the language back to IBM with the recommendation that it be implemented tested... 'and then we'll see. '"
In the same issue, the editorial advised us "If IBM announces and implements a new language - for its whole family... one which is widely used by the IBM customer, a de facto standard is created.? The Letters to the Editor for the May issue contained this one:
"Regarding your story on the IBM/SHARE committee - on March 6 the SHARE Executive Board by unanimous resolution advised IBM as follows:
"The Executive Board has reported to the SHARE body that we look forward to the early development of a language embodying the needs that SHARE members have requested over the past 3 1/2 years. We urge IBM to proceed with early implementation of such a language, using as a basis the report of the SHARE Advanced Language Committee. "
It is interesting to note that this development followed very closely the resolution of the content of Fortran IV. This might indicate that the planned universality for System 360 had a considerable effect in promoting more universal language aims. The 1964 October issue of Datamation noted that:
"IBM PUTS EGGS IN NPL BASKET
"At the SHARE meeting in Philadelphia in August, IBM?s Fred Brooks, called the father of the 360, gave the word: IBM is committing itself to the New Programming Language. Dr. Brooks said that Cobol and Fortran compilers for the System/360 were being provided 'principally for use with existing programs. '
"In other words, IBM thinks that NPL is the language of the future. One source estimates that within five years most IBM customers will be using NPL in preference to Cobol and Fortran, primarily because of the advantages of having the combination of features (scientific, commercial, real-time, etc.) all in one language.
"That IBM means business is clearly evident in the implementation plans. Language extensions in the Cobol and Fortran compilers were ruled out, with the exception of a few items like a sort verb and a report writer for Cobol, which after all, were more or less standard features of other Cobol. Further, announced plans are for only two versions of Cobol (16K, 64K) and two of Fortran (16K and 256K) but four of NPL (16K, 64K, 256K, plus an 8K card version).
"IBM's position is that this emphasis is not coercion of its customers to accept NPL, but an estimate of what its customers will decide they want. The question is, how quickly will the users come to agree with IBM's judgment of what is good for them? "
Of course the name continued to be a problem. SHARE was cautioned that the N in NPL should not be taken to mean "new"; "nameless" would be a better interpretation. IBM's change to PL/I sought to overcome this immodest interpretation.
Extract: Definition and Maintenance
Definition and Maintenance
Once a language reaches usage beyond the powers of individual communication about it, there is a definite need for a definition and maintenance body. Cobol had the CODASYL committee, which is even now responsible for the language despite the existence of national and international standards bodies for programming languages. Fortran was more or less released by IBM to the mercies of the X3. 4 committee of the U. S. A. Standards Institute. Algol had only paper strength until responsibility was assigned to the International Federation for Information Processing, Technical Committee 2. 1. Even this is not sufficient without standard criteria for such languages, which are only now being adopted.
There was a minor attempt to widen the scope of PL/I at SHARE XXIV meeting of 1965 March, when it was stated that X3. 4 would be asked to consider the language for standardization. Unfortunately it has not advanced very far on this road even in 1967 December. At the meeting just mentioned it was stated that, conforming to SHARE rules, only people from SHARE installations or IBM could be members of the project. Even the commercial users from another IBM user group (GUIDE) couldn't qualify.
Another major problem was the original seeming insistence by IBM that the processor on the computer, rather than the manual, would be the final arbiter and definer of what the language really was. Someone had forgotten the crucial question, "The processor for which version of the 360? , " for these were written by different groups. The IBM Research Group in Vienna, under Dr. Zemanek, has now prepared a formal description of PL/I, even to semantic as well as syntactic definitions, which will aid immensely. However, the size of the volume required to contain this work is horrendous. In 1964 December, RCA said it would "implement NPL for its new series of computers when the language has been defined.?
If it takes so many decades/centuries for a natural language to reach such an imperfect state that alternate reinforcing statements are often necessary, it should not be expected that an artificial language for computers, literal and presently incapable of understanding reinforcement, can be created in a short time scale. From initial statement of "This is it" we have now progressed to buttons worn at meetings such as "Would you believe PL/II?" and PL/I has gone through several discrete and major modifications.
Extract: Introduction
The family tree of programming languages, like those of humans, is quite different from the tree with leaves from which the name derives.
That is, branches grow together as well as divide, and can even join with branches from other trees. Similarly, the really vital requirements for mating are few. PL/I is an offspring of a type long awaited; that is, a deliberate result of the marriage between scientific and commercial languages.
The schism between these two facets of computing has been a persistent one. It has prevailed longer in software than in hardware, although even here the joining was difficult. For example, the CPC (card-programmed calculator) was provided either with a general purpose floating point arithmetic board or with a board wired specifically to do a (usually) commercial operation. The decimal 650 was partitioned to be either a scientific or commercial installation; very few were mixed. A machine at Lockheed Missiles and Space Company, number 3, was the first to be obtained for scientific work. Again, the methods of use for scientific work were then completely different from those for commercial work, as the proliferation of interpretive languages showed.
Some IBM personnel attempted to heal this breach in 1957. Dr. Charles DeCarlo set up opposing benchmark teams to champion the 704 and 705, possibly to find out whether a binary or decimal machine was more suited to mixed scientific and commercial work. The winner led to the 709, which was then touted for both fields in the advertisements, although the scales might have tipped the other way if personnel assigned to the data processing side had not exposed the file structure tricks which gave the 705 the first edge. Similarly fitted, the 704 pulled ahead.
It could be useful to delineate the gross structure of this family tree for programming languages, limited to those for compilers (as opposed to interpreters, for example).
in PL/I Bulletin, Issue 6, March 1968 view details
in PL/I Bulletin, Issue 6, March 1968 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 PL/I Bulletin, Issue 6, March 1968 view details
in Computers & Automation 21(6B), 30 Aug 1972 view details
The exact number of all the programming languages still in use, and those which are no longer used, is unknown. Zemanek calls the abundance of programming languages and their many dialects a "language Babel". When a new programming language is developed, only its name is known at first and it takes a while before publications about it appear. For some languages, the only relevant literature stays inside the individual companies; some are reported on in papers and magazines; and only a few, such as ALGOL, BASIC, COBOL, FORTRAN, and PL/1, become known to a wider public through various text- and handbooks. The situation surrounding the application of these languages in many computer centers is a similar one.
There are differing opinions on the concept "programming languages". What is called a programming language by some may be termed a program, a processor, or a generator by others. Since there are no sharp borderlines in the field of programming languages, works were considered here which deal with machine languages, assemblers, autocoders, syntax and compilers, processors and generators, as well as with general higher programming languages.
The bibliography contains some 2,700 titles of books, magazines and essays for around 300 programming languages. However, as shown by the "Overview of Existing Programming Languages", there are more than 300 such languages. The "Overview" lists a total of 676 programming languages, but this is certainly incomplete. One author ' has already announced the "next 700 programming languages"; it is to be hoped the many users may be spared such a great variety for reasons of compatibility. The graphic representations (illustrations 1 & 2) show the development and proportion of the most widely-used programming languages, as measured by the number of publications listed here and by the number of computer manufacturers and software firms who have implemented the language in question. The illustrations show FORTRAN to be in the lead at the present time. PL/1 is advancing rapidly, although PL/1 compilers are not yet seen very often outside of IBM.
Some experts believe PL/1 will replace even the widely-used languages such as FORTRAN, COBOL, and ALGOL.4) If this does occur, it will surely take some time - as shown by the chronological diagram (illustration 2) .
It would be desirable from the user's point of view to reduce this language confusion down to the most advantageous languages. Those languages still maintained should incorporate the special facets and advantages of the otherwise superfluous languages. Obviously such demands are not in the interests of computer production firms, especially when one considers that a FORTRAN program can be executed on nearly all third-generation computers.
The titles in this bibliography are organized alphabetically according to programming language, and within a language chronologically and again alphabetically within a given year. Preceding the first programming language in the alphabet, literature is listed on several languages, as are general papers on programming languages and on the theory of formal languages (AAA).
As far as possible, the most of titles are based on autopsy. However, the bibliographical description of sone titles will not satisfy bibliography-documentation demands, since they are based on inaccurate information in various sources. Translation titles whose original titles could not be found through bibliographical research were not included. ' In view of the fact that nany libraries do not have the quoted papers, all magazine essays should have been listed with the volume, the year, issue number and the complete number of pages (e.g. pp. 721-783), so that interlibrary loans could take place with fast reader service. Unfortunately, these data were not always found.
It is hoped that this bibliography will help the electronic data processing expert, and those who wish to select the appropriate programming language from the many available, to find a way through the language Babel.
We wish to offer special thanks to Mr. Klaus G. Saur and the staff of Verlag Dokumentation for their publishing work.
Graz / Austria, May, 1973
in Computers & Automation 21(6B), 30 Aug 1972 view details
in Belzer, J. ; A. G. Holzman, A. Kent, (eds) Encyclopedia of Computer Science and Technology, Marcel Dekker, Inc., New York. 1979 view details
Intermission
In December 1955, I left the 650 world by joining IBM to write a processor for doing scientific work on the IBM 705, which was a decimal and alphanumeric machine designed originally for commercial work. PRINT I was a considerable step up from the system we had done for the 650. Although PRINT I was interpretive in execution, an initial process removed as much redundancy as possible from the executing program. PRINT was also the first load-and-go system.
PRINT I was designed and built in the same office complex as FORTRAN, and I watched that work with interest. Design started in December 1955. I gave a talk to the Western JCC in February 1956. PRINT I was field operational by August. Obviously it was time for new work!
in Annals of the History of Computing, 08(1) January 1986 (IBM 650 Issue) view details
in Annals of the History of Computing, 08(1) January 1986 (IBM 650 Issue) view details
in Bemer, Bob "Computer History Vignettes" (Web published, retrieved 2000) view details
Resources
- FOTRANSIT web page
external link - Smillie, Keith "A Restrospective Look at Some Computers and Languages"
external link