UofC reminiscenses

I was in high school when I discovered computers and the only computer access I had was at the university of Calgary. Obviously there was a conflict between the requirement that I attend school while what I really wanted to do was programming. I wrote programs in high school classes and skipped as many classes as I could get away with to head out to UofC to be closer to computers. At this time in Calgary, the high school I was going to had a new, "high tech" way of keeping track of student attendance, and this was by encoding every students name on a punched card and sending the cards of absent students to the principals office to be entered into the computer. One common method of preventing one from being counted as absent was to grab ones own card by intercepting the student who happened to be carrying the cards of absent students for a given class to the principals office at some point before their destination. I never understood why people would want to hang around the school while skipping class. Mentally, I probably skipped almost all of the classes I attended since I was in another reality while physically present in class. What I needed a way of leaving the school for the day and not being counted as absent, and I used technology to my advantage. I should note that school was the greatest interruption to my education that I have ever encountered.

At this time, all programs were entered into the hulking IBM 360 which was the main UofC computer via punched cards and it was a simple matter to "borrow" my punched cards for various classes for a day or so, and to add extra punches using a keypunch at the UofC data center so that it would no longer register under my name when run through the card reader at the principals office. Ignorance of office staff about computers was no different in 1969 than it is now and when my card caused errors, no-one knew how to deal with it. I skipped a lot of classes in that year and the next, and managed to get all the credits I needed to graduate from high school in one semester less than everyone else. I spent this 5 months in 1970 mainly playing with computers at UofC.

In 1969-1970, programming was a totally different experience than it is at present. It was very much a mental exercise as one had to create the algorithm, code it in FORTRAN, execute the FORTRAN code within ones head to ensure it would work, punch the code on cards, and then carefully check the cards for errors. The worst case turnaround time I recall was 72 hours and it is hard to communicate in 2001 the disappointment one felt when ones program didn't compile because a comma was absent. All one could do was to repunch the offending card, and submit ones card deck again and wait for output, hopefully <72 hours.

I now recognize that the programming I did back then was not really about computer programming, but rather about creating a mental model of the computer in ones head which allowed one to very efficiently create programs. Interactive programming now requires very little wetware processing of the program since one immediately gets feedback of whether one has made stupid syntax errors in ones code. The goal in 1969 was to write ones program, punch the cards, and have it execute correctly the first time. This happened very frequently in that era. Now, I am embarassed to state how many interactive compilations I have done to get a program to run; once I counted and gave up counting after I corrected 30 stupid syntax errors. Since the code/complile/debug cycle is so short, I can get a lot bigger programs running in much less than the 72 hours that it took me to go through one cycle of this process in 1969. I think that having a wetware computer simulator has some advantages, but I can't prove it. It might be one of these situations where, since I did it this way, that is the proper way to do things. Hacking wetware seemed to be the way to go in 1969, and I still think it is a method worth looking into.

The TSS/8 that I had access to during my last 6 months at UofC was an environment which would be much more familiar to current computer users. Feedback was relatively immediate (within 5 seconds or so) and for the first time I was able to write programs interactively. Interestingly, this was not done. Having become so acclimatized to a batch programming environment, most work on developing an algorithm was done on paper with extensive wetware simulation. The final result was usually just typed in and the big advantage of the interactive environment was the compiler (usually PDP8 assembler) flagging syntax errors immediately so that productivity was greatly enhanced. FOCAL was an interpreted language supplied by DEC at this time although Basic was also available. Those of us who were programming purists shunned such languages as we were interested in direct interface with the hardware which meant assembly language.

For the assembly language programmer, the TSS/8 was nirvana as the year before I had done my assembly language programming primarily in wetware converting assembly instructions into octal code and then entering them into PDP8 memory via panel switches. It beats not having computer access, but there are better ways of spending ones time. Paper tape wasn't that much faster when one had to read in paper tapes multiple times for each pass of assembler and when intermediate output was generated on a paper tape punch. The TSS/8 had a hard disk which allowed instantaneous access to ones data (note that the definition of instantaneous has been getting faster every year). It was impressive to enter ones assembly language program, have syntax checked in a minute or so and then have the program running in 5 minutes instead of the 2 hours it would have taken to do the same process via paper tape (it would have reliably been 2 hours since anyone who didn't have a program entry error rate of <= 0.1% or less didn't stay around for very long).

It was the TSS/8 that first made me realize the power of the regenerative algorithm that those of us who were into computers were using to create seemingly unlimited progress -- it has been 31 years now, and I still see no sign of the rate of progress diminishing. The head hacker of the TSS/8 system who was paid by UofC to maintain the system did his programming in a very public manner -- there was a blackboard in the TSS/8 room at Uof C on which he would post bits of system code (all in PDP8 assembler of course) and ask for simplifications, or he would be found before this board attempting to improve the function of the time sharing system. This is where I picked up most of my OS fundamentals and was first exposed to the meritocracy of hacking -- no-one cared who you were if your code was better than theirs.

The other new aspect of the TSS/8 system was that computer games were now available. Eliza was the first program I used that could be called a game, and I was impressed with how lifelike it was (just goes to show how much experience with life I'd had at that point). There was a lunar lander game which I thought was really neat and I now realize that it required a large part of the lunar landar emulation to be done in wetware; you needed imagination to play this game.

The game of Life was described in Scientific American mathematical games in October 1970 -- I remember this very well as the first thing I and other nerds did was to create programs to run Life in batch mode. I used to feel guilty about how much paper I was producing printing out endless generations of life patterns on the IBM 360 line printer, and tried doing coding the game in PDP8 assembler -- it worked, but I had no video terminal to display the data which would have eliminated the problem of paper waste (I was in my environmental phase at this time, and I now view this as one of the temporary aberrations of youth).

One difference I noticed between myself and other UofC hackers was that I was always looking for practical applications for my programs. Things like time sharing systems were neat, but given the choice to help code the OS or write a program to do numeric integration of the equations of motion of the N-body program, I would chose the latter. I wrote a program to maintain the membership of the environmental group I headed at this time and, while it probably would have taken less time to manually sort the cards of peoples names, I created a database structure which could be manipulated in various ways to produce the list one wanted, albeit in batch mode. I still have my early programs and will be scanning them to disk in order to document what I have done. Partly, the reason for this is to demonstrate prior art to invalidate assinine software patents.