I wrote my first computer program when I was a sophomore at MIT. I wrote my most recent one in 2020 in conjunction with the law review article I authored about robotic cowboys.
MIT's biggest lecture hall was room 26-100. Across the hall from 26-100 was a big room in which the Institute had just recently installed an IBM 7094 computer. The computer represented the state-of-the-art. It occupied the entire room. It accepted input in the form of punched cards and magnetic tape and provided output in the form of punched cards and a teletype-machine printouts. When wishing to run a program, one it would punch the lines of program code onto cards using keypunch machines in satellite facilities distributed around campus. One would enclose the stack of cards, making sure there were in the proper order, with a rubber band and drop the program request through a slot into a box in the computer room. The operators would take the stacks of cards, more or less in the order in which they had been submitted, put them through a card reader, which sent the requisite bits of information along to the computer, either directly or via a magnetic tape.
When a program had run, or when some bug prevented its running successfully, the operator would tear off the printed output from the teletype and wrap it around the programmer's cards, put the rubber band back on and drop the package in another box accessible from the hallway. Rarely was the actual computer time more than a second or two, but the overall process took a half day or more for student programs. Debugging a program took quite a while. One would submit the program, get back the deck of cards with an error message after a half day or more, correct the errors, resubmit the deck, and so on.
Two programming languages were available to us: FORTRAN, then relatively new, and IBM assembly language. Fortran is much easier to program in because it came closer to natural language. In assembly language, one had to specify each step the computer took such as retrieving an item from memory, putting it into a register in the central processing unit, performing a calculation on it, and storing the results back into memory.
The cards were configured to receive punches in 80 columns. The user sat at a keyboard designed like a typewriter keyboard, and the machine moved the card across, stopping so that each column could receive the punches in the number and position indicating an alphanumeric character. The noise the keypunch machines made was not unpleasant. A kind of "thwack!" as the punches went through the card in each column, and then a slight buzz and "clunk!" when the card was ejected.
During my sophomore year, my fraternity brother, Rich Lucy, and I got jobs in MIT's instrumentation lab, working for John Kirk, a wonderful former naval aviator, who was the father of my fraternity brother Joe Kirk. MIT's instrumentation lab work on classified inertial guidance systems for the United States Department of Defense. Rich and I had to obtain secret security clearances to work there. The project we worked on was the inertial guidance system for the Polaris sea-launched intercontinental ballistic missile system, intended to be able to reach the Soviet Union with multiple nuclear warheads. The warheads were designed so that they were independently maneuverable after they separated from the missile body. Our job was to help design the guidance systems to steer those warheads. Radio communication with the warheads was out of the question, because it could be compromised, so the guidance system had to remain stable enough without external data for a 30 minute missile flight, notwithstanding the enormous g-forces on it when the missile was launched
Getting this right required lots and lots of computer simulation of the flight, adjusting different parameters and seeing what effect that had on missile accuracy. The Instrumentation Lab had available to it a large mainframe computer manufactured by Honeywell Corporation. This computer ran a high-level programming language called "Mac." The language was not unlike Fortran in many ways, but it had been written to be especially efficient in handling matrix computations, thousands of which were necessary to manage the coordinate systems involved in missile navigation.
Rich and I spent most of our days at desks in the Instrumentation Labs' temporary World War II buildings on Albany Street, in Cambridge, writing code in the Mac language. As the junior men on our team, it fell to us to take our programs and program modifications and those of our more senior colleagues across town to the Honeywell computer, located not far away from the Sloan School, facing the Charles River. At the computer facility, the keypunch machines were in the computer room itself. The sounds were quite evocative, a combination of the thwack-thwack-buzz-clunk from the keypunch machines, combined with the floop-floop-floop of the vacuum-modulated tape drives. The facility was very active. Not only were Defense Department programs being run, but the software for the Apollo mission to the moon was being stimulated at the same time.
By the time Rich and I finished two academic years working at the lab part-time and two summers full-time, we were pretty good programmers. Sometimes not good enough, however. I was taking the course in the aircraft propulsion systems, 16.30. The computations to compute thrust and other variables in a turbojet engine are quite complicated and require repeated numerical iterations. I got the bright idea that I could simplify the task by writing a computer program and running it on the Instrumentation Lab computer. The problem was that my program had so many bugs that I ran out of time debugging it and had to revert at the last minute to hand calculations.
All of us at SAE took an elective course in introductory computer programming 6.43. The course required us to complete various programming assignments using Fortran and assembly language. In typical MIT style, taking the course was like drinking from a fire hose. The assignments were difficult and they come came one right after another with short deadlines.
When I started my masters program at the Sloan School, one of the requirements was to write an assembly language program that computed day of the week from month, day, and year. This was an interesting exercise, but by then, I knew enough about programming that I did not have much difficulty with it.
When the Sloan school yielded to my brief naval service and then to work as an application engineer at Lockheed-Georgia company, I wrote a Fortran program on Lockheed's timesharing system – timesharing had been a major project at MIT just as I was leaving, and Lockheed's defense work put it on the front line of computing technology – that helped the marketing branch manage the many Defense Department request for proposals and Lockheed's response to them. I got the program written, debugged, and demonstrated it to my boss and his bosses. It was deployed into the contract administration department, and I received an award from the company for the innovation.
I was up to my ears in Atlanta politics during the Lockheed days. When Rodney Cook, one of my moderate Republican alderman and state representative friends, decided to run for mayor, we needed to convince the Atlanta business community that he was a viable candidate. I volunteered to collect voting data at the precinct level and write some computer programs that would relate demographics to voting behavior. The analytical approach was not unlike what I had read about the 1960 Kennedy campaign's doing, combining census data with historical voting data.
I don't remember asking for permission to use Lockheed's computers for this purpose. But I had free access to the timesharing terminals, so no one noticed or cared what I was using them for. I spent many hours writing a family of Fortran programs that evaluated Atlanta voting behavior, using multiple regression analysis to build models. I made photographic slides of the computer printout – that's how we made Lockheed marketing presentations – and give a slide presentation to the leaders of the Atlanta business community in Atlanta's top private club, the Capital City Club, with Rodney and his campaign manager, Paul Coverdell there. The presentation went well, although I don't think any of the businessmen understood the mathematics behind what I had done. I was credible enough, that they accepted the bottom line: that Rodney could win, and that he had a sophisticated campaign staff.
I didn't do any computer programming during the five years I worked for the federal government and went to law school. I didn't have time. But after I moved to Philadelphia, to Conrail, in 1976, I read the computer industry trade press with great interest, and knew that RadioShack, Apple, and Commodore were about ready to bring out consumer-oriented microcomputers. I was a regular customer of RadioShack, and so when RadioShack brought out its Model I TRS 80 in 1978, I immediately bought one. The computer had a keyboard and a CRT display, but no printers existed, and no practicable storage devices. Supposedly, one could record the contents of RAM onto a tape cassette and then load it back in later, but the volume adjustment on the cassette tape recorder had to be just right for both the recording and the playback. As a consequence, the process worked only about half the time it best
But the little TRS 80 was a computer. It had memory of 4 kB. It could run a version of Basic, similar to FORTRAN, and do all of the kinds of computations and character manipulations that were built in to Basic.
I had a Polaroid camera and made up for the lack of a printer by taking pictures of the computer screen. Within six months or so, RadioShack came out with a printer. It was a crudely modified teletype, weighed close to a hundred pounds and could print only capital letters, but hey, it was a printer. I bought one immediately. By 1979 RadioShack also came out with a floppy disk drive, and I bought one of those, as well. Storing programs on the floppy disks was much more reliable than trying to do it on the tape cassettes, but still kind of flaky: one had to treat the disks gently.
I began to experiment using the little computer for text processing, but its utility was limited, first by the unavailability of lowercase letters, and then, after new printer software filled that gap, by the inability to transfer text information electronically to anybody else except by physical exchange a floppy disk.
At about the time I went to Villanova Law School in 1981, RadioShack introduced its TRS 80 Model II, a much more capable machine, with 32 or 64 kB of memory, a bigger screen, 8 inch floppy disk drives, and serial ports to which one could attach a telephone modem--they were just becoming available, at 300 bits per second
By the time I had a contract to write my first book, IBM had released its PC, and then the IBM PC AT, a much faster machine. I bought an AT and took it to my law school office
I had befriended the Villanova University computer people and set up an account on the VAX machine on main campus. By then, modem technology has progressed to the point that exchanging data via telephone modem was useful. So I wrote assembly language programs (I tried Fortran, but it could not execute fast enough to keep up with the Model II’s buffering of the data flow) that would extract data from the word processing program running on the Model II, send it as an ASCII stream over the telephone lines to the VAX computer at Villanova, and then, separately, send the contents of the VAX files across the telephone lines into my IBM AT. Though cumbersome, the results were quite good. I was able to exchange files between home and office computer and work on them in both places without much loss of formatting information. Shortly thereafter the law school got a proprietary timesharing word processing program. I wanted to write programs that would permit the exchange of data between my computer and the word processing system, but the vendor would not unlock the proprietary interface. I led the charge with the Dean to replace the proprietary system with PCs, which, by the late 80s, had become capable of doing the word processing job.
By the late 1980s, people in academic computing were beginning to talk about networks linking university and research lab computers. Bitnet was one of the first, with the Internet in the background.
When Steve Frankino came to Villanova as Dean and had lunch with me I told him that I was considering shifting my scholarly focus from labor and employment law to law and technology. I was going to have to wait too long to get my turn at the top in labor law, and I could be a pioneer right away in law and technology. He was supportive. When John Dunlop offered me the chance to do a sabbatical semester at Harvard, shortly after that, I told John that if I went to Harvard I was going to work on information technology and not labor and employment law. He was a bit surprised but agreeable and supportive.
My semester at Harvard was the same semester in which the Kennedy School and Harvard’s computer science department sponsored a major national symposium on the future of the Internet. All of the pioneers of the Internet were there. I was the only l law professor participant, and so I wrote some of the earliest scholarship on the Internet in the legal issues that it presented. My interest in the underlying technology meant that I wanted to understand how the Internet worked at the bit-and-byte, semiconductor, and circuit level. I participated in all of the technical discussions and was active in asking questions. It was an efficient way to learn a lot in a short period of time at the feet of the masters.
When I went back to Villanova after my sabbatical, I was eager to set up an Internet server at the law school. By virtue of my Harvard experience, had pretty good contacts with others sharing my interests. I got a small grant from an organization called NCAIR, and set up an Internet connected server containing government information and made it available to the public—a forerunner of firstgov.gov and of Cornell’s excellent Legal Information Institute.
By then, I knew the following programming languages: assembly language for the IBM 7090; assembly language for the Zilog Z80, the processor and the RadioShack TRS 80; Fortran; Honeywell's Mac; Basic; Pascal; and a little bit of LISP and Prolog. In about 2005, I set out to learn C++. I spent many hours on tutorials, and was able to write a few baby programs, but getting the strong typing right was so frustrating that I did not do much more with it. I learned a little bit of UNIX along the way as necessary to organize file structures and permissions on the Villanova VAX and similar machines. I learned PHP and was reasonably proficient with it when I wrote the interface for the Iraqi Kurdistan project.
When I was working on the Employee Dismissal and How to Practice Law With Computers books I wrote some programs in Ashton Tate’s dBase IV programming language. The program presented screens for entering basic information about judicial opinions dealing with wrongful dismissal, stored them in a database, and produces output in the form of copy for supplements to my Employee Dismissal book. We we got our first sailboat and I was applying what I knew about aerodynamics to sails, I wrote a little program in Basic that accepted wind velocity, wind direction, and the angle of sail with respect to the boat and computed the lift vector.
In 2015, I decided to learn Python in a serious way, simply because it seemed to be the dominant higher-level language, alongside C++. I took a series of online tutorials, earned some kind of certificate in basic Python proficiency wrote a number of programs simulating textile mills production, which aided my law review article on the beginnings of the Industrial Revolution in America. I also wrote a program to evaluate settlement offers in wrongful dismissal cases and included it as an appendix to one of the supplements to my Employee Dismissal book.
Having honed my python skills, I was ready to write a program that illustrated what a cowboy robot could do if assigned the task of herding cattle. This program became a part of my first cowboy article, Rise and Fall of the Cowboy. The program made some assumptions that simplified the task, most significant of which was that it assumed operation on level ground, free of obstructions Aside from that the program allowed the robot to detect an animal that had drifted away from the herd, to close on it, to position itself just inside the animal’s flight zone at an angle with its shoulder that would cause it to move back into the herd, and then to stop when the animal had rejoined the herd.
During the same time., I took an online course in JavaScript and used it for certain parts of the interface on the Employee Dismissal case evaluation program.
The second intellectual bubble over artificial intelligence occurred in the 1980s (the first bubble was in the 1950s when the press was foaming at the mouth over “electronic brains”) , when I had completed my Employee Dismissal book and was beginning to write How to Practice Law With Computers. Lots of law professors, legal automation experts, and informatics specialists in Europe were excited about the possibility of legal expert systems, which, it was predicted could perform many functions heretofore requiring human lawyers. I immersed myself in the literature, gave several invited presentations in Europe and around the country on the subject and, because I had expert knowledge in a particular legal domain – the law of wrongful dismissal from employment--and also had programming skills, decided to write an expert system on wrongful dismissal from employment eroded in the Pascal language. Finished, it had several thousand lines of code.
I do not cut any corners on the design and coding of the program. It handled every legal branch of wrongful dismissal law and tracked the analytical structure of the book. It also asked questions of the user much as I, as a lawyer skilled in the subject matter, would ask. The questions were organized hierarchically so that the answer to one question determined what subsequent questions were asked. When the program was finished, I took it to Washington, to my friends and fellow labor lawyers at Morgan Lewis and Bockius and I played with it. At first, they were impressed, and I was proud of the program’s sophistication. After using it a few times, however, we realized two things: first of all, even a lawyer completely unskilled in the subject matter would learn enough about it after using the program a few times to handle things on his own without the program. Second, it was impossible to design questions for the user that did not, on the one hand, call for legal conclusions, beyond the ken of a lay client, without, on the other hand, losing the analytical links that drove the content and sequencing of the questions. Not only was natural language processing necessary, a technique that did not then exist in the marketplace, but the natural language had to be embedded in an intelligent intellectual framework that reflected the law
In the third intellectual bubble over artificial intelligence, natural language programs do operate usefully and very limited domains such as airline and Amtrak reservations and cell phone troubleshooting – although any cell phone customer is likely to have his own opinion about their effectiveness
