In 1969 or 1970, before we were married, Margie and I ran into Bill Gosper at the restaurant "Joyce Chen's Small Eating Place" on Massachusetts Avenue, a bit north of MIT. I knew Bill from the Artificial Intelligence group, where I was finishing up my Ph.D. thesis. Since we arrived for lunch at the same time, we shared a table. I could have happily talked with Bill about computer programming during the entire lunch, but that didn't interest Margie. Thus I tried to move the conversation to something else, anything else.
But despite a considerable effort on my part, Bill proved to be incapable of talking about anything other than mathematical and technical subjects. He couldn't talk about sports, in which he had no interest. He couldn't even talk about the weather, which he never noticed. Actually, I'll bet I could have engaged him in a discussion of Chinese food, about which he was an expert, but somehow that didn't occur to me at the time (even though we were in a Chinese restaurant). Towards the end of the meal, Margie got bored with our technical conversation, and left to take a walk outside while we finished up. It was several minutes before Bill noticed that she was gone, asking with surprise, "What happened to Margie?". Bill was the quintessential computer "hacker". Note 1
When I was a graduate student in the artificial intelligence lab in the second half of the 60s, the word "hacker" was a term of respect. The first definition of "hacker" in the Jargon File Note 2 reads "A person who enjoys exploring the details of programmable systems and stretching their capabilities, as opposed to most users, who prefer to learn only the minimum necessary." The word has now taken on a negative connotation in the popular press, referring to programmers who break into other systems with malicious intent. That is not the way it was used when I was a student, and is not my usage in this entry.
The rise of the computer brought along with it people who love to work with them and to understand them in depth. There had always, of course, been people with this sort of analytic propensity. I was one of them. We were the sort of people whom the teachers depended upon in high school to run the projectors. We were the "technical nerds", although the term "nerd" was not used at the time, as I recall. But the computer is a perfect focus for people with these propensities towards minutia. Particularly in the early days of computation, computers required their users to delve into their operation in great detail.
Because the things we say or write in everyday life are interpreted by thinking people and not machines, the listeners (and readers) can fill in missing detail. If you e-mail someone and say you have just seen a mutual friend named "Steven", the reader will likely understand that you meant "Stephen". If you just thought, "Huh?", don't go into computer programming.
In an e-mail, okay, so you spelled the name wrong - unless you know a lot of people named Stephen (or Steven), the reader can probably figure it out. But to a computer, a file named "Stephen" and a file named "Steven" are utterly distinct, just as if one of them were named "John" and the other were named "Mary". Change a single letter, and you've got something else. Note 3 People whose brains naturally see the minute detail necessary to catch these small differences have a good start towards being excellent computer programmers. And that's what many of the hackers were like.
Computers are also completely predictable - they do exactly what you tell them to do. It may not have been what you meant to tell them, but what you do tell them to do is exactly what they will do. That predictability also is appealing to some people. Some of the computer hackers I worked with seemed to prefer to deal with computers over dealing with people, since people are generally quite unpredictable.
A friend and classmate, Martin Schrage, was assigned a programming project in some course that he was taking. Each of the students in the course was allocated a certain amount of computer time for program debugging. Time on the 7094 in the computer center (which looked sort of like the one to the right) went for around $300 an hour at the time, so each student was allocated only a few minutes of "CPU time" (time spent running his program on the computer's "Central Processing Unit"). Martin keypunched his program onto a deck of Hollerith cards ("IBM cards"), and submitted it to be run.
In the late 60s, before there were time-sharing systems and personal computers, programs were run under a system called "batch processing". A number of submitted programs were combined into a "batch", and run one after the other. Martin's program was written in a language called "MAD", short for "Michigan Algorithm Decoder", a language much like FORTRAN. The first step in running such a program was to have it processed by another computer program called a "compiler". The MAD Compiler's job is to translate a program written in the MAD language into commands which can actually be executed by the machine. Note 4
But the compiler did not pass Martin's program on to the next stage, the actual running of the program, because it detected an error. As a joke, whenever one or more errors were detected by the MAD Compiler, it printed a picture of the Mad Magazine comic book's mascot Alfred E. Neuman, including his motto, "What, me worry?". The only available high-speed output device of the day, a "line printer", was a character-only printer, so the best it could do is shown below:
The error comment above shows an error in program line 5172 of "INTEGER CONSTANT TOO LARGE". In Martin's case, the error was something like:
Not understanding why he had gotten this error, Martin sought help.
To support the 7094 computer, IBM had provided MIT with a couple of full-time consultants to assist with its operation. These were two women in an office in the computation center, to whom you could go with any problems. Martin showed up for a consultation.
Now, Martin is a very sociable guy, and he tried to establish some sort of rapport with the two IBM consultants. Martin didn't usually have much trouble with this. He began with some casual conversation, instead of charging directly into his question. But the IBM consultants were having none of this. They were all business, and only wanted to know what his problem was. They wouldn't laugh, or even smile, at any of Martin's jokes. They were, it turned out, a pair of female computer hackers. Note 5
When Martin explained the problem with his program, at first all the consultants could do was parrot the error printed by the compiler: "Line 580 is inaccessible". When Martin tried to explain further, they went into greater detail about what "inaccessible" meant: line 580 could not be reached in the course of operation of the program. That is, the program code just above it did not drop down into it, and nowhere in the program was any command containing a "GOTO 580". Line 580 could not be reached. The compiler considered that to be a fatal error, and refused to pass the program on for execution. Note 6
But Martin persisted. He pointed out that his program contained what is called a "computed GOTO". This meant that it computed a number (let's call it LINE) and then executed the statement "GOTO LINE". Martin then walked the consultants through the operation of his program, to show that "LINE" could in fact take on the value 580. Line 580 was accessible. Something was wrong.
Once this was pointed out, the consultants got more animated, although they still didn't crack a smile. They gave Martin some test code to insert into the program, told him to re-run it and return to them with the results. He did so, but the error persisted, and the reason was still not clear. They then gave him a more complex batch of tests to run. Martin pointed out that he was only a student, with a maximum of 3 minutes of CPU time, which he had almost used up. No problem for the IBM consultants, who after all controlled the scheduling of the computer. On the spot, they credited 10 minutes of additional CPU time to Martin's account.
This debugging process went on for quite a while. Whenever Martin returned with the results of a run, the consultants would flip open an enormous program listing, the 15 cm. (six-inch) thick printout of the program code of the MAD compiler. Poring over it, they tried to figure out what could possibly be going wrong.
And then one day, they got it. One of them found the problem, and it was a bug in the MAD compiler itself. Their bug report would now appear in the next MAD compiler update document, and the bug would be fixed in the next release. And in the document, their names would appear as responsible for identifying the bug and finding the solution. The two women were ecstatic, and smiling from ear to ear. It was the first time Martin had observed in them any sort of human emotion.
Note 1: Bill Gosper attained legendary status as a computer hacker, and has been mentioned in a number of books on the subject. One of the better known is "Hackers: heroes of the computer revolution", by Steven Levy (Anchor Press / Doubleday, Garden City, NY 1984, ISBN 0-385-19195-2). Bill rates 42 references in the index. You can also look Bill up on Wikipedia, where you can learn about his many subsequent accomplishments in computer science and mathematics.
Bill was hardly the only brilliant and quirky denizen of the Artificial Intelligence Lab in the late sixties. Among the others mentioned in the book that I knew (some better than others) were Richard Greenblatt, Tom Knight, Marvin Minsky (my thesis advisor), Stewart Nelson, Russell Noftsker, Peter Samson, David Silver, and Jerry Sussman. I also knew Alan Kotok from the Tech Model Railroad Club ("TMRC"). He was the designer of the PDP-6 and PDP-10 computers we used in the lab. I'll write more about some of my experiences in the lab in subsequent entries.
The entire "Hackers ..." book now seems to be available on the web in PDF form - click on that link to see it. Although I loved the book, particularly having known many of the people who were discussed, my 1986 printed copy does have some errors, some of which have been corrected in the PDF version. For instance, it mentions the "TICO" text editor, later corrected to "TECO" in the PDF version (it stood for Tape Editor and Corrector). The book refers to Electrical Engineering course "No. 641", actually written "6.41" (at MIT, "Course 6" is Electrical Engineering, and all courses in that department start with a six followed by a decimal point). My guess is these errors sprang from verbal interviews by the author, since "TECO" is indeed pronounced like "tico", and course 6.41 is usually read as "six-forty-one" (everyone at MIT would know that the "six" represents the department number). [return to text]
Note 2: Click here to see the Jargon File describing some of our computer hacker language. If that link is not maintained in the future, just do a search on "MIT Stanford jargon" (without the quotes), and you'll find numerous copies. [return to text]
Note 3: In fact, a file named "Stephen" and a file named "stephen" are also completely different in many file systems, just because one of them starts with a capital letter and the other doesn't (they are distinct in any UNIX file system, but in fact they are not distinct in Microsoft Windows). [return to text]
Note 4: A compiler translates program lines in a "high-level language" into commands which can be directly executed by the machine. For example, a program line might read:
The "250" is a line number, as it was then customary to assign a number to every line in the program (among other reasons, if you dropped your deck of IBM cards, line numbers allowed you to use a machine called a "sorter" to physically re-sort the deck). The compiler translates the rest of the line into a sequence of instructions that causes the computer to pick up the contents of a memory location holding the value "PRINCIPAL", add to it the contents of the memory location holding the value "INTEREST", and store the resulting sum in the memory location holding "PAYMENT". [return to text]
Note 5: I'm being a bit loose with the "hacker" honorific here. As the "Hackers" book notes, "The sad fact was that there never was a star-quality female hacker. No one knows why. There were women programmers and some of them were good, but none seemed to take hacking as a holy calling the way Greenblatt, Gosper, and the others did. Even the substantial cultural bias against women getting into serious computing does not explain the utter lack of female hackers. 'Cultural things are strong, but not that strong,' Gosper would later conclude, attributing the phenomenon to genetic, or 'hardware,' differences." [return to text]
Note 6: I guess the writers of the compiler figured that if a portion of your program could not be executed, you probably had made some sort of mistake. One could argue that a portion of the program being inaccessible should not have been a fatal error (preventing execution), but should have just generated a warning. Perhaps in those days, there was a strong bias against any possibility of wasting the computer's time.
Little did anyone know that there would one day be a humorous computer program called "Monty Python's Complete Waste of Time". My wife bought it for me as a gift. When she asked the salesman in the store if he thought I'd enjoy it, he said yes, but added, "I have to warn you, though, it's a complete waste of time. [return to text]