<nettime> Extra Life

["David S. Bennahum" <davidsol@panix.com>]

This is an excerpt of my upcoming book, Extra Life: Coming of Age in Cyberspace [http://www.extralife.org/] for ZKP5.

When We Were Young
by David S. Bennahum


For the few of us into computers at Horace Mann in 1982, the computer room on
the third floor of Tillinghast Hall was the greatest place at school. With its
lead-paned windows overlooking the football field, its polished floor and rows
of terminals in tidy rows, the computer room existed as our private library and
club room. During free periods, when other kids might go outside to play touch
football or gossip in the cafeteria, I could be found upstairs at a terminal,
playing games and programming with my friends. There, amid the silence,
interrupted by the clicking of keys and the soft tapping of chalk on the
blackboard, we competed fiercely to be the best programmers. It was a place
where things happened quietly, but explosively.

Pranks were a natural part of the room. I'd written programs that fooled
seventh-graders into thinking our shared computer, a Digital Equipment
Corporation PDP-11, was conscious. Others had found ways to fool skilled
programmers into thinking the computer could no longer add properly (2 + 2 =
5!). Creativity ran rampant. The walls were covered with elegant "ASCII art" -
pictures of Snoopy and the New York skyline we'd made from collections of
letters that from a distance assembled themselves into an image. A few had
mastered the eight-pen color plotter, learning to produce marvelous geometric
shapes, swirling vortices, and rippling landscapes. I was in awe of some of the
older kids who'd reverse-engineered the PDP's operating system and were trying
to build a new one from scratch.

The computer room was also a safe haven, a family of sorts. We were mostly boys
- though a few girls spent time there - and many of us came from families with
  divorced parents. I faced turmoil at home, living between my mom and dad,
separated from my sister. Another boy, Misha, faced such acrimony at home as
his parents underwent a particularly bitter breakup that he threw himself into
programming with relentless intensity, eventually creating an after-school
business writing programs for Wall Street corporations and earning enough money
to pay for college himself. In the computer room, all the worries of the real
world faded away, replaced by the exhilaration of the quest, a gleeful sense of
discovery, and the joy of being best at something.

I was exposed to a  remarkable computer curriculum, and nearly everything I
know about computers and technology comes from those years on the third floor
of Tillinghast. My friends and I were among the first at our Bronx school, and
in America, to have computers at home. At 13 I owned an Atari 800 with 48K of
RAM; Jeremy Bozza had an Apple II; Misha had a TRS-80; others had Commodore 64s
and VIC-20s. At school we used the PDP, which, like our early home computers,
was special because it was so transparent. The barrier between us and the
machine was low; we could fairly easily get to the innards of it. It was a
unique time, the Golden Age for computer and kid. The machine was available to
us unconcealed, stripped to its component parts, at the same time when most
adults barely understood what we were doing. The evolution of the machine
briefly matched the evolution of our adolescent selves, becoming a vessel and
partner, a co-conspirator in our coming of age.

One of the rare adults who did understand computers was our teacher, Mr. Moran.
He was a big man with a red beard, red hair, and heavy forearms like a
lumberjack's. His eyes were luminous gray-blue, and he always wore silver
glasses, which softened his appearance, giving him an intelligent presence, as
if he noticed everything. He existed in my mind as a descendant of Vikings, a
benevolent warrior, at the helm of our ship, guiding the room through waters of
knowledge. 

Mr. Moran left Horace Mann in 1988. Today he doesn't teach kids; he teaches
adults through the Global Knowledge Network, an outfit that provides continuing
education to corporate employees. For Mr. Moran (his first name is Ed, but I
still find it impossible to call him anything but Mr. Moran), who has taught
for 23 years, computer education has shifted from learning how to program to a
form of digital bricolage where prewritten subroutines are linked together to
form programs. Mr. Moran doesn't even program anymore. A few months ago he
removed C++ from his home computer to make room for Windows 98. "It hadn't
occurred to me at the time, but this was my last compiler," he told me the
other day, referring to C++.   "I still can't quite get over the fact that I'm
sitting here with a computer that has no programming capability whatsoever,
unless you count things like Word macros, which I don't."

If Mr. Moran finds it difficult to program computers these days, it's easy to
see how difficult it is for 14-year-olds. Computers are now infinitely more
powerful than they were when I mastered them. They're also far more opaque. For
a kid now, getting beneath Windows 98 or Mac OS 8.0 is nearly impossible. Our
priority has shifted to teaching people how to be Power Users: dexterous at
using software, rather than creating it. Added power and opacity, however, has
its virtues. Using computers "out of the box" is a lot easier than it used to
be. Clicking on an icon requires less study than going into a Basic programming
environment and typing RUN. These systems have broadened access and turned what
was mostly a hobbyist subculture into a part of mass culture. What is lost is
the idea that kids can ever learn to understand computers, or that any of us,
as computer users, can have fundamental control over what they do. We're
supposed to know how to use the tools, not make the tools!  .

Mr. Moran taught us to make things, using the elements of computing as our
tools; the notion that we would become merely educated consumers would have
seemed ludicrous and unworthy as a goal. I grew up feeling I really understood
computers. While I don't program anymore (the last time I programmed was in
1993, when I wrote databases for a management consulting company), the
experiences I had at home with my Atari and in the computer room with Mr. Moran
and my classmates have given me a perspective that, no matter how opaque and
turbocharged computers become, lets me use them without feeling bewildered and
dominated.

In 1979, when Mr. Moran asked Horace Mann's administration to provide him with
US$200,000 to buy the PDP-11 and create a sophisticated computer room, the
future was supposed to be different. "Some trustee asked me why I needed so
much money for so much equipment," he recalled. "Why didn't we just get a few
PCs and teach everyone how to use a wordprocessor and that would be it. I
replied that someone had to design the future wordprocessors, and I wanted my
students to be able to do that. That seemed so obvious to me then, and still
does today. But as computers get easier to use, and more people use them, they
are getting harder to really understand, and fewer people really understand
them."

When I entered the computer room for the first time, I felt the future was
hidden there, waiting to be discovered. There are moments between people in
that room that stick in my mind as permanent testaments to the kind of learning
we experienced. In his quiet way, Mr. Moran had created something unique at
school: student teachers. There was no boundary between learning in class from
Mr. Moran and learning out of class from "Superusers" and younger students who
might one day become Superusers. Superuser was a title awarded by Mr. Moran to
the best programmers in the room. Being a Superuser was not an academic
distinction - though any student who earned it typically received straight As
in computer class - but a mark of responsibility. Superusers were system
administrators. They, as much as Mr. Moran, ran the room. 

It was a post we all wanted. A Superuser was expected to be present whenever
Mr. Moran was out of the room, but Superusers didn't just babysit; they
installed and upgraded new programs that were then made available to everyone.
They also wrote software, creating applications that otherwise wouldn't exist.
In part, this reflected necessity. In the early 1980s, when high school
computer education was in its infancy, student-crafted software was essential
to the curriculum. Schools nationwide hadn't begun to invest in computer
courses, and few companies provided software environments for teaching below
the university level. 

Mr. Moran, through organic evolution, trial and error, created an open system,
both in the way the computer functioned and in the social fabric of the
computer room. The machine and the kids existed in symbiosis, each a part of
the other. Without the student system administrators writing programs, updating
software, managing the younger students, answering their questions, Mr. Moran
would have been incapable of being teacher, guide, administrator, and sometimes
policeman. More important, centralized control by one teacher was antithetical
to the ethic of exploration and gleeful discovery fostered by access to
computers. Mr. Moran recognized this and promoted its inverse -
decentralization and communal ownership of the computer system - by empowering
kids to strive for total access. 

The Superuser had no restrictions: With the title came the right to access any
other student's account, including that of other Superusers. In principle, if a
Superuser wanted to crash the system, delete every file, snoop anywhere, he
could. This was not reverse psychology or a sophisticated ploy to divide and
conquer. Rather, it reflected the belief that for kids to be well-educated,
responsible citizens in the digital age, knowing how computers worked would not
be enough. Their education would be incomplete without a genuine understanding
of the moral and ethical questions brought up by information technology. Who
owns software? Where does someone's electronic property or territory begin and
end? At what point do shared systems become public? I couldn't have expressed
these convictions outright back then. They were ingrained in us as we went. As
was a certain pride - encouraged by Mr. Moran without any fanfare - in what we
were accomplishing. We were not covering well-worn p!  aths in our learning. We
were striking out, sometimes wildly, into a little-known territory. Reward for
our journeys came in the form of profound and gut-wrenching insights, palpable
moments of learning. One of these occurred in my junior year, while working on
Cheese, the most complex and ambitious programming challenge Mr. Moran ever
gave us.

That fall of 1984, I'd enrolled in Advanced Placement Computer Science, the
final course Mr. Moran offered, counting for college credit. In AP Computer, as
we called it, Mr. Moran taught us Pascal, a programming language designed to
give students good programming habits - modular, well-documented code. Invented
in the late '60s by Niklaus Wirth, a Swiss educator and computer scientist,
Pascal charmed me with its elegance. Unlike Basic, Fortran, or Assembly
language, which I'd learned in previous years, Pascal had no line numbers.
Rather than taking the long, rectangular shape of rows of programming
instructions, Pascal programs were sinewy. They wove down the page, with
indented lines indicating subroutines. Pascal floated as a poetry of
algorithms. AP Computer demanded mastery of Pascal. 

Mr. Moran's trimester-long Cheese assignment, meant to simulate the workings of
a cheese factory, was the ultimate test of our skills. Each of us had to write
a Cheese program to handle inventory control, managing piles of data on what
cheeses were in or out of stock - Gouda, Havarti, Brie, Swiss, and so on - and
reorder what was missing. The most difficult part was the reporting functions.
The program had to provide statistics on which cheeses sold best, what
combinations of cheese shipped most frequently, and financial averages on the
cost of typical cheese orders. These then had to be printed out in neat reports
- the kind a factory manager would like to read. 

In the spring of my junior year, Cheese permeated the computer room - cheese,
cheese, cheese. Scraps of sorting functions, with tell-tale variables like
"Muenster" or "cheddar," would be left, half erased on the board. Printouts,
sometimes shredded, other times left underfoot, would clutter the area around
the printer. Picking them up would reveal Š cheese. I began to feel that
Cheese was all that mattered. And it was while working on Cheese that I had my
epiphany, a moment of learning, of the sort that stays with one ever afterward.

One procedure kept crashing my Cheese program. It seemed simple, a routine
control structure. The procedure read from the database of cheese inventory,
looking for a particular cheese. The idea was to scan each record, checking if
it equaled the cheese value sought. If it found a match, the procedure copied
that record's address and returned to the previous part of the program. Mission
accomplished. 

If, however, the cheese was not there, the procedure tried again, moving down
the list to the next record. This was a generic conditional loop, designed to
persist until the desired result is attained. But for some reason, it didn't
work. If the chosen cheese didn't come up in the first dozen or so records, the
program fatally crashed, claiming it had run out of memory. That made no sense.
It was just a loop. The procedure looked like this:

PROCEDURE get_cheese(VAR wanted_cheese : cheese, output_location : integer);
VAR 
	cheese : cheese
	location : integer

BEGIN {procedure get_cheese}
	read_database(cheese, location)
	IF cheese = wanted_cheese
		THEN 
			output_location := location
			END
				ELSE
					get_cheese(wanted
					_cheese; location)
	END; {procedure get_cheese}

The idea was to scan the database of cheese by calling the get_cheese
procedure. Get_cheese goes through the database using another procedure called
read_database, which I created to handle all data search requests throughout
the entire Cheese program. That's the power of Pascal: You write one procedure
and can use it throughout the rest of the program, rather than rewriting the
command over and over. If read_database does not find a cheese value that
matches what you want, get_cheese moves down to the next record by calling
itself. I pictured the whole thing like a GOTO loop. 

The little pointer moves down the procedure, and if read_database does not
return what is sought, then get_cheese invokes get_cheese(wanted_cheese;
location) and starts over, until the wanted cheese is found.   But then it
crashed.

[PROGRAM STOPPED OUT OF MEMORY]
$

Why?

Grappling with my program at school, I knew the get_cheese variable couldn't be
the problem. It had worked flawlessly in other procedures throughout my Cheese
program, so I loaded the debug program that comes with the Pascal compiler.
Debug let me step through the code, one execution at a time, watching exactly
what the PDP was doing. That time, debug didn't help. I watched as the program
stepped, one instruction at a time, just as I thought it should: moving down
the procedure and calling itself until the cheese is found. But every time,
around the 12th iteration of the loop, the program crashed. Why, why, why? It
turned into one of those ghost-in-the-machine moments, when you're convinced
computers are much more mysterious than you realize. Perhaps sentient.

Jeremy and Kenny were in the room, too, across from me, on the other side of
the table. I was embarrassed to ask Mr. Moran for help in front of them. What
if it's a stupid problem? So I ran debug again. Maybe I had missed something. 

[PROGRAM STOPPED OUT OF MEMORY] $

Mr. Moran sat at his terminal grading programs. Behind him, the blackboard,
scuffed with yellow chalk, revealed the wonders of logic gate design, control
structures, database design, hexadecimal arithmetic. On his desk at the head of
the table, a sign read "To err is human. To really foul things up, you need a
computer." I could have just asked him, but I was afraid of wasting his time
with what could turn out to be a silly question. "Mr. Moran," I said quietly
from my terminal near his desk, "Can you help me?" He looked up and told me to
come over.   I pulled up a chair beside his desk and laid out the program. We
looked at it together.   "This procedure is crashing, and I don't know why.
See, this is what it's trying to do." I explained it to him. Mr. Moran used his
silver pen as a pointer, just as I imagined the computer did somewhere in the
abstract matrix of memory. He followed the lines, pointing.  "Hmm," he said.  I
felt better. "Hmm" was good. That meant my question wasn't so stupid after all.
"Hmm. It looks right," he said.  I was thrilled. Mine was a smart problem.
"Let me see," he said, getting up. We went to my terminal and I ran debug,
taking him to the crash. I pictured the magic pointer, moving up and down, like
a finger passing along a stack of books.  Mr. Moran looked at the code.  "Of
course," he said, suddenly smiling, his face turning red. "This isn't a loop.
It's recursive. Every time you call get_cheese it calls itself inside itself.
If the condition is still false, it calls itself again, until the computer runs
out of memory." I was confused. "It calls itself inside itself?" Inside itself?
Then it happened, as if the floor fell away from my feet and I too was falling,
the bigness of the whole thing suddenly in my stomach. This isn't a loop! It's
a snake eating its tail! It's infinity, the procedure self-replicating inside
itself! It's creating a whole new universe inside another universe, and again
and again, and would do so forever, were it not for the limits of the PDP. One
inside the next, except each one is both the same size yet inside the preceding
one, an impossible simultaneous state of two existences. Of course the PDP
crashed. Nothing finite can contain the infinite.  I'd never felt that before,
the reality of infinity. There it was, a wordless revelation.  "Thanks Mr.
Moran," I said. And he went back to his desk.

-------
This excerpt originally appeared in Wired magazine, September 1998.  Duplication for commercial purposes forbidden.
---
#  distributed via nettime-l : no commercial use without permission
#  <nettime> is a closed moderated mailinglist for net criticism,
#  collaborative text filtering and cultural politics of the nets
#  more info: majordomo@desk.nl and "info nettime-l" in the msg body
#  URL: http://www.desk.nl/~nettime/  contact: nettime-owner@desk.nl