This is a book review done as part of a collaborative project with FingerLakesWanderer, who is reviewing the same book.  Read this, then read hers (or vice versa)!

I first learned to program in 1975. It was a course in FORTRAN taught at my high school. I'd tell you that it used a punch card machine but it wasn't quite that advanced. You see, we didn't have a punch card machine. We had instead a lower-tech thing: FORTRAN coding sheets. These allowed us to write our FORTRAN programs, give them to someone who would carry them across town to be typed by a professional typist onto punched cards, and then sent to the computing facility, where the program would be run on the IBM 1130 computer that served our community. Student runs would be done after hours, of course—just before the computer was shut down for the night. Computers only worked a normal work day, just like people. The computer had to rest overnight. You can perhaps imagine how frustrating this process was.

Fortunately, I had insisted on taking typing the previous term—the term before the first FORTRAN course was offered. I had to push to get into that class, since its main function was to teach girls to be secretaries. But I had a manual typewriter at home and at 25 words or so a minute, I was at the upper bound of what I could do with one finger typing. Officially, I didn't get a whole lot faster, because they counted off severely for making typos. But if you didn't mind the occasional typo, I was a lot faster touch typing on an IBM selectric. And when “glass” terminals came along complete with a delete key, I was a lot faster. But I'm getting ahead of myself. The point, though, is that I could type.

And so rather than wait for days for computer runs, I asked if I could run across town and type my own cards and take them to the data center myself. It was an unusual request, but they allowed it, and it meant I could get same day turnaround on the programs I wrote—even fixing syntax errors sometimes the same day. It felt positively civilized.

The only problem was that although I was determined to do really fun things with computers, the class kept getting boring assignments like “Read a number off the card deck and if it's an odd number, print a 1 on the line printer or else print a 0 on the line printer.” I'm not sure if that was an exact problem we were assigned, but was close enough to right. In particular, the output part was right. We were to turn in a piece of line printer paper with exactly one character on it.

For me, the pressure to become like a machine had begun. I was determined to resist it. Even with technology this primitive, it seemed obvious to me that there was fun to be had. So I wrote a program that printed:

  1
 11
111
  1
  1
  1
  1
11111

I quickly outgrew the course and there was no one left in our school available to teach me. Fortunately, my friend Dave's dad was somehow involved in the acquisition of the a new computer for our school, and he asked Dave and me to “test” it over the summer, to make sure it was ready for use by students in the fall. We had a manual, which was good because it ran BASIC, not FORTRAN. Though at the time I didn't really have a firm concept of why that was very different. It was sort of like the difference between British and American. We just started in programming and looked things up when our intuitions about FORTRAN didn't work. We wrote all kinds of programs, testing—and defying—the limits of what that computer could do

We worked until the wee hours many a night. The machine had only 8K of RAM memory, but we wanted to run a 32K program we'd seen in a magazine, so Dave figured out how to load programs in pieces from the cassette drive, implementing a crude form of what today might be called a kind of virtual memory system, though in a more low-tech way. The computer interpreted BASIC in hardware. It had no operating system. But we were inventive and we forced it to do our bidding. That's what a computer was, after all—something to do our bidding. So we just assumed it would do what we wanted it to do, and we were limited only by our own imagination.

I saw the words “text editor” in a magazine somewhere. That sounded fun. So I wrote a program that did what I imagined was text editing. It had a big 2-dimensional space of characters that you could type into, like virtual paper. I remember later when I was attending MIT someone taught us about their text editor and they got to the part about the “search” command. I said out loud, “Search. What a good idea.” My text editor hadn't had search. But that was a limitation of imagination, not of the computer. If I'd thought of it, I could have included it.

I worked a lot in school and community theatre back then. The following summer, after graduating from high school, Dave and I again got access to the computer while I was working on the The Wizard of Oz. I remember the costume and make-up people on the show were trying to figure out how to make sure that each of the munchkins had a slightly different costume and make-up scheme. I was trying to find ways to have computers improve my life, so I wrote a program to spit out different combinations of costume colors, makeup colors, etc.

It was my custom in those days to write parodies of the plays I was working on, so when I scrawled out a hand-written draft, it occurred to me I could perhaps get the computer to print out copies. So I enlisted my friend Antoinette, who was a faster typist than I was, and explained my plan to her. She would do the typing into my text editor. It was hard to explain what a text editor was or why it would be useful, but I promised her she'd understand when she saw it. It was night and the school was all locked up, but I had a key to the room with the computer. Antoinette muttered, “Kent, if this was anyone but you I wouldn't believe this was just about typing something up.” It would never have occurred to me to do anything else, and I guess she knew it. We got to the computer room and I explained my text editor. She did great with it and soon we were able to print a number of copies of my parody for use in a performance at a cast party.

My crowning achievement using that computer was when I saw in a book the output from a program that played a game called ANIMAL. It would tell you to think of an animal and it would proceed to guess it. If it didn't know, you'd teach it your animal. The interaction went something like this:

I didn't have the source code for the game and it puzzled me that it could learn. BASIC has fixed data structures, I told myself. It was not obvious how to make a game that could keep growing. But I eventually solved the problem and was able to write such a program. The trick was not to store the data inside the computer. Quite literally, I was thinking outside the box. It was my first use of the tape drive on the computer, and it had the nice effect that it remembered what it had learned after it shut down.

But it continued to bug me that the conversation was so clumsy. It wasn't how people talked. But I was lucky enough to take a course in LISP taught by Joseph Weizenbaum, of ELIZA fame, an introductory AI course taught by Pat Winston, and a course in computational linguistics taught by Bill Martin. These courses gave me the skills to again push my on the boundaries of what computers could do, and armed with my new knowledge, I rewrote the ANIMAL program to use a transformational grammar that allowed conversations with it to work more naturally. Interactions looked more like this:

The future of computers, and indeed of mankind, looked very bright back then.

Several companies sprang up to sell machines specifically designed to run LISP, my programming language of choice.

I was constantly pushing the boundaries, but so was everyone I knew. While others wrote programs that played tic-tac-toe using numbered squares or coordinates, or perhaps the click of a mouse, I wrote a program that would let you draw an X or an O and would figure out how to respond to your gesture. I wrote programs that had databases of local restaurants and made recommendations based on parameters you could input about what you were looking for in terms of ethnicity, quality, money, etc. These kinds of things later appeared as products on the market, but when I was writing them, there was no marketplace, no way to sell them.

And it wasn't just me that was doing this kind of thing—everyone I knew did this. It was what one did.

The machines we programmed, called Lisp Machines, were expensive, but the cost was coming down. Everyone I knew who used them was very smart. I somehow imagined that as the use of these computers became more widespread, the world would become full of smart poeple. (Okay, that wasn't the brightest conclusion I ever drew. But I was full of optimism.)

But the world didn't go as we imagined. As computers and computer use spread, it seemed to be that it was dumbed down. Instead of investing in programmers to make computers smart, it was easier just to teach people to cope with computers being dumb. Sure, there was some innovation. But to someone who was there at the time, it was—well, it was like you can imagine it was for people in the space program of the 1960's. Here they were, landing on the Moon by the end of the decade, just as Kennedy had told them to. They figured by the end of the century we'd have gone to Mars. But in fact, it's unlikely we could today get safely to the Moon and back. That's what modern computers feel like to me. Yes, they're faster. Yes, there are a few whizzy gadgets. But that's all. Somewhere along the line, things stagnated.

In those days, computer jobs were about solving the world's great problems. One hired a programmer to help think about those problems. It would have been almost unthinkable to tell the programmer what language to program in or how to structure the problem. The whole point of programming was to confront an issue you didn't understand. So why would you tell someone how to do a task you didn't understand.

Increasingly, though, computer jobs have become about things we do understand. How could that be? Do we suddenly understand all the world's problems? No, we don't. We just don't go after those problems any more. There's too much variability. We just do the same old things in different packaging. Easy things. Predictable things. Boring things. Things that don't challenge programmers and that don't challenge users. Computer science has become a kind of brain mush, providing an endless supply of cute little apps and widgets with very little substance behind them.

That's not to say nothing useful is ever done with computers. Certainly there are tools for natural language, tools for mapping, and cool input mechanisms for games on Apple's handhelds. But a great many of today's programs are just text and graphics editors or players, databases, browsers, and games. There might be a hundred or two legitimately different kinds of things, but how many thousands, perhaps millions, of people have been involved in programming for how many decades to bring us those? It still surprises and saddens me how little has happened with all that time and expenditure.

Enter Jaron Lanier. Lorraine Berry (FingerLakesWanderer) suggested I read his book, You Are Not a Gadget. I cannot say enough good things about this book. For some, these ideas may be new. To me, it tells a familiar story, about things and people familiar to me. But either way, it's an articulation of a great many things that have bugged me about computers for a long time. The trend is wrong, and he's put his finger on the issues in a way really no one has.

The book is a beautifully presented criticism of the state of society's relationship with computation, of the way in which we are trending toward having people be the dull, uninteresting, expendable, ill-paid part of a collection organism. He directly takes on the issue of the purpose of all of this, asking us to question for ourselves whether we're getting what we want and need, asking us to challenge the autopilot we seem to be relying upon.

He even tries to offer some suggestions about how to fix things, though that's probably my least favorite part. I have quibbles with with some of those suggestions, and they seem to me like a distraction because even if his suggestions are definitively wrong, his criticisms and his call for suggestions are still terribly important. Still, it's good that he acknowledged the need to find positives, and I can't seriously fault him for trying to give some examples as ice-breakers to get people started in a long-overdue discussion.

Much of the story I've told you here is about me, and it's told in cursory form. I rarely have time to go into the detail on such matters that I'd like to. But Lanier has taken the time to do it in book form in great detail—and very artfully. It's the kind of book I wish I had written. Perhaps sometime I'll do something like it—or perhaps something very unlike it. The book is a call to arms for people, to not lose their individuality in sea of technology, to take hold of technology and drive it somewhere, not just wait to be rolled over by it.

I highly recommend You Are Not a Gadget.