I have almost no memory of which book on ALGOL I had in school in 1973, although it would have been for the Burroughs 6700 computer, and therefore probably for Elliot Algol. I remember it mentioned the maximum number of array dimensions was something like 17, which thrilled me because the number of array dimensions had been a limitation on the previous two languages I had learned. It probably also had a random number generator function defined for that compiler since I wrote a tic tac toe program in ALGOL in 1974, though the program was not interactive.
In the absence of the textbook I used, here is a sampling of other books on Algol-60 from that era:
This is a small-sized instructional book from 1964 with British spellings. I like the vintage/'60s look of it, with its greenish cover and all. This is the only reference book I have of ALGOL that is immediately available to me, so I thought I'd scan the entire book as a convenient, authoritative reference for everybody. There also exists a hardcover version of this book with a slightly different cover.
front cover, exterior
front cover, interior - p. n1
pp. n2-n3
pp. n4-i
pp. ii-iii
pp. iv-v
pp. vi-vii (Contents)
pp. viii-1 (What is ALGOL?)
pp. 2-3
pp. 4-5
pp. 6-7
pp. 8-9
pp. 10-11 (Three Useful ALGOL Constructions)
pp. 12-13
pp. 14-15
pp. 16-17 (Simple Programs in ALGOL)
pp. 18-19
pp. 20-21
pp. 22-23
pp. 24-25
pp. 26-27 (Arrays and 'for Statements')
pp. 28-29
pp. 30-31
pp. 32-33
pp. 34-35 (Compound Statements and Blocks)
pp. 36-37
pp. 38-39
pp. 40-41
pp. 42-43 (Procedures and Procedure Declarations)
pp. 44-45
pp. 46-47
pp. 48-49
pp. 50-51
pp. 52-53 (Further Features of ALGOL)
pp. 54-55
pp. 56-57
pp. 58-59
pp. 60-61 (APPENDIX: A Complete Problem)
pp. 62-63
pp. 64-65
pp. 66-67
pp. 68-69 (SOLUTIONS TO EXAMPLES)
pp. 70-71
pp. 72-73
pp. 74-75
pp. 76-77
pp. 78-79 (Index)
pp. 80-81
pp. 82-83
pp. 84-85
pp. 86-87
pp. 88 - rear cover, inner
rear cover, outer
| references #1 claim | references #2 claim | references #3 claim | refs #1 | refs #2 | refs #3 |
|---|---|---|---|---|---|
| go to | goto | . | [1] | [2][3] | . |
| ^ | power | . | [1][3] | [2] | . |
| and | /\ | . | [1][2] | [3] | . |
| or | \/ | . | [1][2] | [3] | . |
| not | ~ | . | [1][2] | [3] | . |
| eqv | equiv | == | [1] | [2] | [3] |
| imp | impl | => | [1] | [2] | [3] |
| tan function omitted | tan function included | . | [1][3] | [2] | . |
| rand function omitted | rand function included | . | [1][2][3] | [4] | . |
References:
[1] Reeves, C.M., and M. Wells. 1964. A Course on Programming in ALGOL 60.
Chapman & Hall.
[2] http://burks.brighton.ac.uk/burks/language/other/a60rr/syntax.txt (5-1-05)
[3] http://www.csci.csusb.edu/dick/samples/algol60.syntax.html (5-1-05)
[4] http://users.tpg.com.au/adsln4yb/Guess/guess.a60 (5-1-05)
According to the information I've been able to gather, the computer at our university in 1973 was a Burroughs 6700 computer, which means the version of ALGOL we learned was probably Elliot Algol. The compilers for Burroughs computers were written in machine language that was tailored to the ALGOL language. Unfortunately, unlike the first two computer languages I learned, whose books and syntax I learned quite well, my enthusiasm for ALGOL was much lower, and as a result I remember correspondingly less about our textbook. Possibly our textbook wasn't even a book, but maybe just a photocopied manual.
My diminished enthusiasm might be valuable to analyze,
since it was in striking contrast to the previous two languages I had learned eagerly.
Some major differences in 1973 were partly due to the differences between high school and
college, rather than in my degree of respect for the ALGOL language itself.
Some big differences for me then were:
I found ALGOL quite easy to learn since I had already learned two other imperative languages that were very similar. (In fact, BASIC had been based on both ALGOL and FORTRAN syntax, though I didn't know that at the time.) All I had to do was to remember the syntactical differences-- to put := instead of =, to put a semicolon at the end of each line, etc.-- and I could mostly pretend I was still writing programs in BASIC or FORTRAN. The things that most delighted me about our ALGOL compiler were: (1) it allowed a large number of array dimensions, many more than either of my other two languages had allowed; (2) it allowed bounds on subscripts, which had impeded programming in the other two languages since mental conversions often had to be made in certain problems where the natural subscripts of the problem did not start at 0 or 1; (3) it allowed descriptive labels instead of arcane numbers. In one of my first ALGOL programs, in a fit of high school immaturity, I enjoyed writing "GO TO HELL;" as a legal ALGOL statement, for example. In general I viewed ALGOL as a perfected version of BASIC and FORTRAN, sort of a programmer's dream language. The main thing I didn't like about ALGOL was that, like FORTRAN, array initializations, array operations, and array prints all had to be done by brute force indexing, whereas in BASIC a single statement would handle any such case. It seemed strange to me that a language that was so ideal in all other aspects should be more difficult than BASIC to use when it came to array operations. To me, a "better" language largely meant "easier to use."
Although all ALGOL texts emphasize that the language allows a mixture of upper and lower case letters, I don't remember that aspect of the ALGOL version we used. I suspect we were constrained to all upper case letters due to the key punch terminals we used.
A narrow L-shaped room lined with key punch machines on both sides was where students typed their programs onto cards. Blank cards would be stacked flat into a receptacle in the machine above the keyboard area, the receptable had a weighted end placed atop it, and with each carriage return a card would be pulled from the holder into the machinery below, where it would be partially visible while being punched. Finished cards would be automatically and mechanically moved to a collecting stack area, and would be seen to be caused to flip over while being placed there. Each keystroke on the terminal would cause a heavy clunk as a single character was punched, and all the terminals operating together in a busy room was relatively noisy. The need for key punch terminals created a theoretical bottleneck, and sometimes we would stand around waiting for someone to get off a terminal, but fortunately this didn't happen too often. Because of the permanence of each punch, it was wise to type slowly. Mistakes could be corrected, however, I believe with a backspace and "delete" key. I believe the punched pattern for deletes was a single column with a punch in every row. I believe there was some convention for continuations at the ends of cards, for very long statements. One had to be careful not to leave cards behind when leaving a key punch machine, since cards weren't free and the next person would likely just add them to their own stack.
In those days of programs on cards, a common way to write one's name on a stack of cards, whose top card might keep changing, was to write on the edge of the thick deck, especially in felt pen. It was amusing to see such writing slowly eroded away as all the bugs were fixed, as the cards with the faulty code were replaced. The only trouble with this labeling scheme is that it worked only for thick stacks of cards.
After punching their cards, students would take their cards to another tiny side room to run them through the card reader themselves. The card reader required a deck of computer cards to be stacked on edge, and it had a springloaded end that held the cards in place. The cards would be read when the appropriate buttons on the reader were pushed, much like sending a fax or running a stack of pages through a photocopier today. The cards flashed through very quickly, and it was impressive to see a thick deck of cards being rapidly read and transfered to the outgoing area of the card reader. Opposite the card reader in the tiny room was a large printer that delivered program listings followed by the results on fanfold paper. A window on the wall opposite the doorway allowed the interior of the air conditioned computer lab to be seen, with technicians walking around various machines, but the computer was either not visible or not distinguishable from the other machines in the room. I believe our class might have been taken inside the computer room once at the start of one course to see the actual computer, but other than that one time, the computer was just a mysterious and unseen entity the entire duration of our schooling, and we dealt with it only in a distant, abstract way.
Fortunately, the turnaround time was not too bad, and we could expect our programs to be run within about 5-10 minutes, so we often hung around in the room, waiting for our printouts to appear. Occasionally we would accidentally code an infinite loop, whereupon we would get thick handfuls of fanfold paper coming out with our listing at the beginning.
College pressures were high. Our computer class teacher was a stickler about programs having been run no later than midnight before the morning they were due. His justification was that he was training us for the real world, which had absolute cut-off deadlines like that. The time of the run was printed onto the beginning of each listing, so it would have been difficult to hide an overdue programming assignment. (I toyed with the idea of writing a program that would do nothing more than print out a listing that identically matched the format of the header's time stamp, so as to be able to sneak by the requirements of a midnight deadline and even a working program, but I never got around to coding such a program.) Our teacher even teased one student who had turned in a listing that listed a time of about 11:58 p.m. by circling the time on his listing and writing a note like "Cutting it a little close, aren't we?"
Such pressures pushed a number of students close to the edge. The student with which I commonly worked on programs admitted after one particularly difficult programming assignment that he had come "close to the edge" that night. Another student on the key punch one day seemed to be freaking out from stress. He was swearing and talking out loud and showing extreme agitation. At first I thought he was just joking around but I began to realize it was for real. In later years I heard of various programmers requiring mental health care, employees demolishing PCs in the workplace with a fire axe, and one security guard shooting his revolver into a mainframe computer, so I no longer find serious stress problems unusual among people who work with computers. To let off steam at the end of one semester when I was living in an upper floor dorm room, I threw handfuls of my computer cards out the window where they fluttered downwards and cluttered the sidewalk and lawn. Unfortunately, I threw one too many handfuls out the window, the dorm manager caught me, and I had to go pick up all those cards.
There was also a certain amount of code sharing going on during programming assignments, the same as goes on nowadays. My friends and I didn't really consider working on programs together cheating, and I still don't, because we were all contributing, learning, and getting hands-on experience, which is the main point of programming assignments anyway. Once we learned the gist of the necessary code, we made copies, added our own modifications, and renamed a few variables to help thwart detection. Our printouts were on large fanfold paper with a large full-page banner having our last name in pseudo large letters. There was one hot brunette who we would sometimes see in the key punch room, who wore red lipstick and honestly looked like a prostitute, and we noted the name on one of her printouts was GRUNSKY, so we thought that was her last name and for a while we referred to her between ourselves as "Munchy Grunsky." However, we later became acquainted with a guy in our class named Grunsky also, then soon realized she had just been using his programs with his name still on the listings. Obviously we weren't the only ones sharing our code during programming assignments.
Some of the programs we were required to write in 1973-1974 in ALGOL were:
