I received my Bachelor of Science in Electrical Engineering in June 1963, after four years of a five-year program in which I was expected to continue on to a Masters degree. This I did, working in MIT's Artificial Intelligence Laboratory, and writing a Masters thesis on generating mathematical formulas in a standard printed format. I then spent a couple of years in Walter Rosenblith's psychophysics lab, but ultimately returned to the Artificial Intelligence Lab to do a Ph.D. thesis in the field of computer science. Thus I had a second stint in the AI lab from September 1966 through June 1970.

The AI lab was a fascinating place, populated by fascinating people. My thesis advisor was Prof. Marvin Minsky (left), a dynamic idea generator. He frequently worked with Prof. Seymour Papert, who spent much of his time developing the Logo computer language for use in primary school education. But of course, much of my time was spent with my peers, my fellow students and the employees of the lab. Many of these were featured in the book, "Hackers, heroes of the computer revolution", by Stephen Levy. ^Note 1  I won't repeat any of the stories in that book, some of them events that I witnessed.

In this entry, I won't strive for any sort of organized coverage of my work and the people in the lab. Rather, I'll just tell a few short stories about some of the amusing events that I witnessed there. Other things that occurred in the lab have been described in my blog entry Moby memory, and in my entries on Richard Greenblatt's chess program MAC Hack VI: I resign, Computer chess via ham radio, Mac Hack VI competes, and Chess stories.

Hackers in the lab had their own jargon. Since the professor John McCarthy had been at MIT, but had departed for Stanford University in California, there was a close connection between Stanford and MIT. Thus the hacker jargon was shared between these two organizations on opposite sides of the North American continent, with nobody using it in the middle. Late in the 60s, the two groups became connected by a data communications network which was a precursor of the Internet, the ARPANET. Funded by ARPA (the Advanced Research Projects Administration), the ARPANET connected only universities and other organizations doing research for the Defense Department. ^Note 2 

I have a story about a word that was used in the lab that I don't find listed in the jargon file, however. The word was "coolie". That word originally described Chinese laborers, particularly those brought to the United States to construct the transcontinental railroad. It came to mean a lowly worker in general, but it could also be considered to have derogatory racial overtones. Nevertheless, because many of the students and employees of the lab considered themselves to be lowly workers, they often referred to each other as "coolies".

The denizens of the AI Lab often frequented the restaurants of Boston's wonderful Chinatown. One day, as a large group finished up a Chinese dinner, David Silver got stuck collecting money from all assembled to pay the bill. As the youngest hacker among us, and the son of the mathematician Roland Silver, David was often called "Sliver" (naturally). He talked out loud to himself as he calculated a reasonable tip. "Let's see," he said, "if I give this coolie $10 ...". At this point, a man (not Chinese) at the adjacent table jumped up. "Don't call the waiter a coolie!", he yelled. Sliver was startled, and completely confused. Looking at us, and indicating the man, he said, "What's this coolie talking about?". It took us a while to calm the man down and defuse the situation.

My thesis work involved computer programming in two different computer languages. One of these was LISP. The acronym stood for "LISt Processor", although some people claimed that it actually stood for "Lots of Irritating Single Parentheses". LISP is a fascinating language that was much used for artificial intelligence research. ^Note 3 

The other language we used was essentially the machine language of our PDP-6 and PDP-10 computers, processed by a computer program called an "assembler", with the name "Midas". When I first arrived at the lab, I tried to read the Midas manual, but I found it completely incomprehensible. It gave a mathematically complete, but entirely cryptic, description of the language processed by the assembler, in a notation called Backus-Naur Form. However, that didn't particularly illuminate how to use it to actually write a program, although that was of course the ultimate objective. The manual was written by Peter Samson, so I sought him out to see if he could explain it to me.

When I found him in the lab, he was involved in a discussion with a group of people. While I waited my turn, I picked up a sheet of paper from the floor nearby. I glanced at it to see whom I might return it to, and found it to be an assembly-language computer program written in Midas. And lo and behold, it looked like any other assembly-language program in any other assembly language. To someone like me who had previously written programs in many assembly languages, it was simple. But by describing the language in exquisite and complete detail, the manual had managed to obscure that fact.

When my turn came to talk to Pete Samson, I was reluctant to tell him that his manual was incomprehensible. Instead, I suggested that it might be improved by including a sample program. He thought that wasn't a bad idea, and wondered what to use. "How about this?", I said, handing him the page I had found on the floor. And so that randomly chosen program became an example in the next release of the manual.

Writing in an assembly language is essentially writing directly in the language of the computers we were using, a Digital Equipment Corporation ("DEC") PDP-6 and later a PDP-10. The user has to understand the instructions of the machine itself in great detail. The PDP-6/10 has an extremely rich instruction set, in which there are always numerous ways to accomplish any particular task. I recall at one point writing a sequence of five or six computer instructions to carry out what seemed to me a fairly simple operation (I'm afraid I don't recall exactly what it was). I was unhappy with the code, because it seemed to me that there had to be a better way to do it. Thus, I did something which I seldom did: I asked the talented hacker Stuart Nelson to look over my code and give me a hand.

Stuart looked over my shoulder at the GE terminal I was using, with its display of 26 lines of 46 characters each. He gave me a way of carrying out the same operation in only two instructions. But, since I had displayed a page of code to him, and explicitly ask for his advice, he went on to suggest some other improvements. By the time he was done, the program on that one page of my display had been reduced to about two thirds its original size, and ran at twice the speed. It was a pretty humbling experience. Fortunately, Stewart knew enough to not wander around the lab doing this unless people specifically asked for his advice. ^Note 4 

Nowadays, assembly languages are seldom used. Instead, programmers write in "high level" languages like Fortran and C and C++. As computers have gotten more powerful, and memory space essentially unlimited, having the smallest and most efficient program has gotten far less important than writing the program rapidly, and creating a program that is easy to understand and modify.

MIT's Computer Science and Artificial Intelligence Laboratory ("CSAIL") has made a number of videos available on work done in the Artificial Intelligence Lab over the years. One of them, called Project MAC (AI Film #104), shows projects underway around the time I was there (caution: it's over 23 minutes long, 55.8 Megabytes). It includes a section on the Greenblatt chess program mentioned at the start of this entry, the famous Mac Hack VI. The section on chess begins at 14:26 in the video. It shows a game being played at the "System Console" (a teletype and a DEC 340 vector display), and includes a view of the chess display that I programmed (shown to the right), my only contribution to the program itself.

The Artificial Intelligence Lab in the sixties was a fascinating place. At a party in Great Neck, I once met Tom Lehrer, the entertainer and, at the time, graduate student in mathematics at Harvard (you can search for his song "Fight Fiercely, Harvard" on YouTube). I complained to him about how long I was taking to finish my Ph.D. thesis. He replied, "The life of a graduate student is the best life on earth. Stay there as long as you can. I may never finish my thesis." And from his biography on Wikipedia, it seems that he never did.

But in the end, I felt pressure from MIT to either finish my thesis and actually get my degree, or leave without it. After graduating, I felt a desire to to out into the "real world", despite the temptations of academe. I also didn't have confidence in the possibility of progress in Artificial Intelligence, given the capabilities of the computers of the day. Indeed, many of the goals of AI research are only starting to appear possible now, when the power of computers is millions of times greater than it was back then. So I don't regret my business career, but it's hard not to try to imagine how my life might have been different had I cast my lot with the hackers.
 

Note 1:   Hackers: heroes of the computer revolution, Steven Levy (Anchor Press / Doubleday, Garden City, NY 1984, ISBN 0-385-19195-2).   [return to text]

Note 2:   ARPA was later renamed "DARPA", adding the word "Defense" in front.   [return to text]

Note 3:   A typical LISP function definition looks like this:

It defines the function "factorial(n)" as "1 if n=0, otherwise n times factorial(n-1)". In other words, it manages to define the factorial function in terms of itself - LISP is "recursive". And it works. In most other computer languages, this function would be defined using iteration - a "DO" loop or "WHILE" loop.

I learned LISP from one of its authors, Dan Edwards, who had been a student of McCarthy's. Since we were working from his class notes, and no books on LISP were yet available, he taught us purely recursive LISP, and didn't even mention its iterative features. One day in class, a students who had somehow gotten outside information asked Dan about the PROG function, the LISP equivalent of a DO or WHILE loop. Dan replied, "The PROG feature is a crutch for incompetent LISP programmers." For the students in our class, it was recursion or nothing.   [return to text]

Note 4:   I once wrote an assembly language program to manipulate some text, with upper-case only characters packed into six bits per character (these "sixbit" characters are the first 64 characters of the ASCII character set). I packed six of these into each of the PDP-10's 36-bit "words" (memory was tight in those days), and used mask-and-shift operations to pack and unpack them.

Some time later, I realized that when I had written my code, I had managed to completely forget about the PDP-10's "byte instructions". I hadn't needed to code the packing and unpacking myself - the computer had a set of instructions, which I had completely forgotten about, to do it for me. We now all think of a "byte" as being exactly eight bits, but for the PDP-6/PDP-10 computers, a "byte" was any number of contiguous bits in any position within the 36-bit word.   [return to text]