Cybernetics in the 3rd Millennium --- Vol. 8 No. 1 --- Apr. 2009

========================================================================
Cybernetics in the 3rd Millennium (C3M) --- Volume 8 Number 1, Apr. 2009
Alan B. Scrivener --- www.well.com/~abs --- mailto:abs@well.com
========================================================================

Top Tech
~ or ~
Architecture in Buildings and Software
(Part Two)

[If you haven't read part one, see the archives, listed at the end.]

APOLOGIA
"We apologize for the previous apology."

-- Monty Python

Patient readers, I'm sorry you've had to wait 14 months for part two
of this 'Zine. I've been concentrating on my self-published book
"A Survival Guide for the Traveling Techie" which is ALMOST ready
for the print-on-demand folks. Meanwhile, the Beta is still available.

( travelingtechie.com )

ARCHITECTURE ADDENDA
"I call architecture frozen music."

-- Goethe

In my haste to get the last issue out I left out two items: this
picture I drew around 1995 to help me sort out architecture trends:

( i164.photobucket.com/albums/u12/c3m_2007/architecture.jpg )

and this actual map of the LA Architecture Tour that we used to navigate:

( i164.photobucket.com/albums/u12/c3m_2007/LA_arch.jpg )

SOFTWARE
"hardware - the easy part of the system"

-- Stan Kelly-Bootle, 1981
"The Devil's DP Dictionary"

( www.amazon.com/exec/obidos/ASIN/0070340226/hip-20 )

The first part of this 'Zine was devoted to architecture, a word
that can be translated as "top tech."

In his polemic on Modern Architecture, "From Bauhaus to Our House" (1981)

( www.amazon.com/exec/obidos/ASIN/055338063X/hip-20 )

Tom Wolfe talks about how, unlike many of the arts, architecture
is hard to ignore. When I was a boy, it was pretty easy to ignore
software architecture, except for the occasional oddball story in
Readers Digest about a billing computer that went bonkers and
sent somebody a gas bill for a million dollars.

Today this is no longer the case. I remember in the early 1990s
I used to say "a bad day in the year 2000 is when your newspaper,
coffeemaker, car and phone all don't work due to software problems."
Well, I pretty much nailed that one. Nowadays software problems
are everybody's business, and represent one of the most efficient
ways we know to destroy value in an hurry.

DOING MY THINKING FOR ME
"Take for example when you go to the movies these days.
They try to sell you this jumbo drink 8 extra ounces of
watered down Cherry Coke for an extra 25 cents, I don't
want it, I don't want that much organization in my life.
I don't want other people thinking for me. I want my
Junior Mints! Where did Junior Mints go in the movies?
I don't want a 12 lb. Nestles Crunch for 25 dollars.
I want Junior Mints!"

-- Jimmy Buffet, 1994
"Fruitcakes" (song) on "Fruitcakes" (CD)

( www.amazon.com/exec/obidos/ASIN/B000002OS8/hip-20 )

The genesis of this issue was a series of three things that occured
in June of 2005, when I was traveling extensively on business.

1) The first was that I read the book "The Inmates Are Running the
Asylum: Why High Tech Products Drive Us Crazy and How to Restore
the Sanity" (1999) by Alan Cooper.

( www.amazon.com/exec/obidos/ASIN/0672326140/hip-20 )

Most things I read come highly recommended by somebody -- my
wife, a friend, or at least some random blogger -- but this one
I found on a neighborhood library shelf, while dusting off my
old trick of starting at Dewey Decimal number 000 and working
my way through the books on epistemology, library science,
the unexplained, Atlantis, UFOs, and cybernetics. These days
you'll also find software design covered in those first few
shelves.

Cooper gave me several useful mental tools, including the
idea that you can classify people by which way they want to
go when boarding an airplane. If you just want to get to
your seat and have a cocktail, and relax while you're flown
someplace, you want to turn right. If you want to see the
cockpit and all of the glowing gizmos that are modern aircraft
instruments and controls, you want to turn left. Our entire
civilization consists of a majority who want to turn right,
depending on technology engineered by a minority who want to
turn left.

He described some recent events in which a U.S. Navy battleship
and a number of Porsche sportscars were rendered "dead in the
water" due to software bugs. He pointed out that both the
U.S. Navy and the Porsche SE company are usually pretty good
at getting what they want from engineers, the former driven by
urgency of surviving naval battles, and the latter maintaining
a 75 plus years reputation for excellence, and yet they're just
as helpless as everybody else at getting what they want from
computer programmers.

This leads him to the question, "What do you get when you cross
a computer and a [fill in the blank]." What do you get when you
cross a computer and a battleship? A computer. What do you get
when you cross a computer and a sportscar? A computer. What
do you get when you cross a computer and a video recorder? A
computer. And so on. What he means by this is whenever you
introduce computer technology into these devices, you inherit
the computer's failure modes. Your highly redundant Space
Shuttle loses its ability to launch and land due to a software
timing problem.

( en.wikipedia.org/wiki/STS-1 )

Cooper also explains how "software engineers" (a.k.a. programmers,
developers, and "the inmates") jigger time estimates to achieve
outcomes they want. In most software development organizations,
the marketing department ostensibly controls what new features
and/or bug fixes will be in each release. But if the developers
don't want to work on something (because it is "inelegant"
or "boring" or "stupid" perhaps), all they have to do is give it
a very long time estimate, and marketing will say they can't wait,
go on without it.

But the most vivid mental tool I got from this book was his
usability analysis of two items usually found in my pocket:

* a Swiss Army knife

* an automobile remote entry fob

The Swiss Army knife, though quite dangerous, rarely injures
its users, because the danger is obvious. The available
functionalities are also obvious.

In contrast, the fob has this red button with a horn icon.
What does it do? It sets off the horn in alarm mode.
The designers typically explain that this is a security
feature, especially for young urban women in parking garages.
But Cooper and I have both found that (a) people universally
ignore car alarms, (b) no young urban women ever use this
feature, and (c) the only time it goes off is by mistake,
becoming, in effect, an "I'm stupid" button.

2) The second thing that happened was that right after reading
Cooper's book I was sent on a business trip from San Diego,
California to Vestal, New York, (near Binghamton, "Twilight
Zone" creator Rod Serling's home town) to solve a customer
problem that neither I nor my boss could solve over the phone.
We'd sent this guy a Micorsoft Access database program, packed
inside a "zip" archive, pretty standard stuff. The only potential
curveball was that we had Windows 2000 in our lab, but the
customer had the new Windows XP which we weren't running yet.
But it shouldn't be an issue, right?

Because of another appointment in central Massachusetts and the
difficulty of lining up puddle-jumper flights that didn't take
all day, I ended up driving about five hours in a rented car
to Vestal, New York.

When I got there I solved the problem in a minute. Come to
find out, in XP the icon for a zipped archive isn't a little
filing cabinet in a vice anymore,

( i164.photobucket.com/albums/u12/c3m_2007/zip_2k.jpg )

it's a file folder with a zipper.

( i164.photobucket.com/albums/u12/c3m_2007/zip_xp.jpg )

When you double-click it, instead of unarchiving its contents, it
appears to OPEN THE FOLDER and show you what's "inside." There
was our database, still inside the zip archive. When you
double-clicked the database icon, it ACTUALLY RAN THE ACCESS
DATABASE, which did fine on all the data READS, but crashed the
first time it tried to WRITE data to the disk. Thank you
Microsoft, for trying to "help" me, adding half of a new feature.

3) The third thing that happened was on the way back from Vestal,
driving through the whole state of Massachusetts west to east
on the Mass. Pike, from Stockbridge to Concord, near Boston.
I took a detour to see the historic Wayside Inn in Sudbury.

( www.wayside.org )

It was the inspiration for Longfellow's "Tales of a Wayside"

( www.amazon.com/exec/obidos/ASIN/1425519547/hip-20 )

and it has a beautiful old grist mill beside it, and I wanted
to take some pictures. I arrived at twilight and the light was
fading fast. I hurried to photograph the mill wheel and waterfall

( i164.photobucket.com/albums/u12/c3m_2007/Wayside_001.jpg )

down by the old mill stream,

( i164.photobucket.com/albums/u12/c3m_2007/Wayside_002.jpg )

and then I spotted an amusing sign in the colonial style that
said, "LONGFELLOW'S Wayside Inn FOOD, DRINK and LODGING for
MAN, WOMEN and BEAST" and I wanted to get one last picture
of it. Right then the batteries in my digital camera decided
to die. No worries, I had fresh batteries in the car.
After I replaced them the camera refused to go on until I set
the date and time. My watch had stopped, so I sat down behind
in the driver's seat, inserted the ignition key, and turned it
until the clock radio lit up, and noted the time. Then, unable
to clearly see the little tiny buttons on the camera, I got back
out of the car and put the camera on the roof so I could see
it better in the twilight. After I set the time I closed the
car door and walked over to the funny sign and got my picture.

( http://i164.photobucket.com/albums/u12/c3m_2007/Wayside_003.jpg )

Upon returning to the car I discovered that the car had decided
to "help" me by locking the doors. The key was in the ignition,
in the on position, and the doors were closed, so I MUST want
the door locked, right? Of course, my cell phone was inside
too.

( i164.photobucket.com/albums/u12/c3m_2007/Wayside_004.jpg )

It took walking over the inn several times to beg the
use of their phone, calling triple-A repeatedly, and otherwise
waiting 90 minutes by the car (I knew tow truck driver's don't
look very long and hard for you) while mosquitos attacked --
it was their favorite time of day! -- before I got back in to
the car.

Once again I had been tripped up by engineers trying a little
too hard to be helpful but not getting it right. It was just
like Cooper's analogy of the Swiss Army knife and the key fob.
I began muttering the quote above from Jimmy Buffet about how
"I don't want other people thinking for me. I want my Junior
Mints!"

And so this was the genesis for this issue. Despite having hear my whole
life that you should "write about what you know," this will only be the
third time I've composed an essay having anything to do with software
design, a field I have worked in for three decades. (The first essay
was on user interface design, in 1980 and the second was on visual
programming, in 1993.) But I've reached a threshold of being fed up
with how badly the whole thing is done, and feel I must protest the sins
of my own profession.

STEAMPUNK
"On two occasions I have been asked, 'Pray, Mr. Babbage, if you put
into the machine wrong figures, will the right answers come out?'
I am not able rightly to apprehend the kind of confusion of ideas
that could provoke such a question."

-- Charles Babbage

In his books on the history of ideas, "The Idea of Nature" (1960)

( www.amazon.com/exec/obidos/ASIN/0195002172/hip-20 )

and "The Idea of History" (1928),

( www.amazon.com/exec/obidos/ASIN/0198239572/hip-20 )

R. G. Collingwood reminds us how difficult it is to imagine not having an
idea. Imagine not having the idea of "software," which is actually pretty
odd. Indeed, in the intellectual climate of the 19th century the basic
concepts of computer programming were very alien. It was into
this world that Charles Babbage attempted to introduce his concepts
of "the Difference Engine" and "the Analytical Engine," and his
girlfriend, Lord Byron's daughter, Lady Ada Lovelace, was the first
person to write software documentation, and also invented the GOTO
instruction.

Babbage's analytical engine, which ran on steam and used gears to build
its logic, had the same architecture as electronic computers when they
were independently reinvented almost a century later. What he called
the MILL we call the PROCESSOR. What he called the STORE we call the MEMORY.

We look in vain in our history and mythology for guidance in managing
this new magic-like power of the mechanical mind, and find very little:
the Sorcerer's Apprentice, Hercules vs. the Hydra, and Jesus' Parable
of the Mustard Seed are all that come to my mind.

EXPERIMENTAL ERA
"What most experimenters take for granted before they begin
their experiments is infinitely more interesting than any
results to which their experiments lead."

-- Norbert Wiener

( thinkexist.com/quotes/norbert_wiener/ )

It is quite amazing how the mathematics, engineering and applications
of computers interacted in the "pre-history" days before we had the
modern programmable electronic computer. I have written before,
in C3M volume 5 number 2, "Even Better Than the Real Thing,"

( www.well.com/~abs/Cyb/4.669211660910299067185320382047/c3m_0502.txt )

of "A Computer Perspective" (1973),

[A] deep and thought-provoking museum exhibit and book of the same
name ... by the incomparable Charles and Ray Eames,

( www.amazon.com/exec/obidos/ASIN/0674156269/hip-20 )

that tells the story of computing devices before the computer, including
the weather-predition work of Lewis Fry Richardson the calculating
machines of Pascal, and the integrating analog computers of Lord Kelvin.

( en.wikipedia.org/wiki/William_Thomson,_1st_Baron_Kelvin )

I am particularly intrigued by the latter, which use disks, balls and
cylinders to find the integral of a rotating shaft's angular velocity.

( upload.wikimedia.org/wikipedia/commons/thumb/2/24/Harmonic_analyser_disc_and_sphere.jpg/800px-Harmonic_analyser_disc_and_sphere.jpg )

In the picture, the disk is spinning with an input velocity, the ball
is constrained to move only left and right, with a spring pushing left
and centrifugal force from the spinning disk pushing it right, and the
cylinder matching the ball's speed, as it traces a larger or smaller
path along the disk.

Once he had an integrator he could -- using Fourier's Integral -- build
a harmonic analyzer, precursor to today's oscilloscopes with waveform
capture and analysis software, such as the "Tektronix WaveStar."

( www.testequity.com/products/567 )

This also enabled a practical application that required harmonic
analysis: tide predicition.

( en.wikipedia.org/wiki/File:DSCN1739-thomson-tide-machine.jpg )

Another fascinating history is "The Computer from Pascal to von Neumann"
(1972) by Herman H. Goldstine.

( www.amazon.com/exec/obidos/ASIN/0691023670/hip-20 )

Just a reading of his table of contents is quite illuminating.

( i164.photobucket.com/albums/u12/c3m_2007/Goldstine_toc1.jpg )

( i164.photobucket.com/albums/u12/c3m_2007/Goldstine_toc2.jpg )

Of course, the great theoretical breakthrough in computing came with
Alan M. Turing's 1936 paper in the Proceedings of the London Mathematical
Society, with the title nobody likes to cite, just saying "Turing 1936."
It is "On Computable Numbers, with an Application to the Entscheidungsproblem."

( en.wikipedia.org/wiki/Alan_Turing )

Turing managed to prove some remarkable things about "computability,"
creating a family of mathematical models called Turing machines, and then
proving that a Universal Turing Machine (UTM) existed that could EMULATE
all the other machines. Turing argued that anything we would consider
"computable" can be done by a Universal Turing Machine. From this
theory the term "Turing Complete" has entered the jargon of programming,
to describe any model, computer language, or mechanism that can do what
a UTM can do. In "A New Kind of Science" (2002)

( www.amazon.com/exec/obidos/ASIN/1579550088/hip-20 )

Stephen Wolfram proved that at least one of the 256 simplest cellular
automaton models is Turing Complete.

Turing also gave us the "Halting Problem"

( en.wikipedia.org/wiki/Halting_problem )

which says that no Turning Machine can reliably tell -- in the general
case -- if another Turing Machine will finish a computation, or get
stuck in an infinite loop. This explains why a program's own estimate
of when it will finish is almost always wrong. The little blue
rectangles showing progress, they lie. Sometimes they even go backwards!
I've seen it!

(And, of course, Turing gave us the Turing Test for Artificial Intelligence.)

( en.wikipedia.org/wiki/Turing_test )

Turing's ideas are intimately intertwined with Kurt Godel's famous
incompleteness theorem, and the so-called "predicate calculus" which
eerily resembles a programming language though it was developed before
computer. All of this is well-explained in "Godel, Escher, Bach,
An Eternal Golden Braid" (1979) by Douglas Hofstadter.

( www.amazon.com/exec/obidos/ASIN/0465026567/hip-20 )

What nobody seemed to realize until everything was declassified 25 years
later was that Turing actually BUILT some UTMs, during World War II, as
part of the secret cryptography work done by the British at Bletchly Park.
This is why William Gibson, in his cyberpunk novel "Count Zero" (1987),

( www.amazon.com/exec/obidos/ASIN/0441117732/hip-20 )

( project.cyberpunk.ru/lib/count_zero/ )

has one of his characters -- an expert on Intrusion Countermeasure
Electronics (ICE) -- say:

"I been in the trade forever. Way back. Before the war,
before there was any matrix, or anyway before people knew
there was one. ... I got a pair of shoes older than you are,
so what the #### should I expect you to know? There were cowboys
[i.e., system crackers] ever since there were computers. They
built the first computers to crack German ice. Right?
Codebreakers. So there was ice before computers, you wanna
look at it that way."

This is documented in the nonfiction book "The Codebreakers: The
Comprehensive History of Secret Communication from Ancient Times to
the Internet" (1996) by David Kahn

( www.amazon.com/exec/obidos/ASIN/0684831309/hip-20 )

and fictionalized nicely in the novel "Cryptonomicon" (1999) by Neal Stephenson.

( www.amazon.com/exec/obidos/ASIN/0060512806/hip-20 )

Meanwhile, at Los Alamos, the Manhattan Project scientists building the first
atom bombs had to do their complex implosion calculations using old-style
"computers" -- human beings operating adding machines, enthusiastically
lead by physicist Richard Feynman. (The Los Alamos guys wouldn't
get an electronic computer until after the war when John von Neumann went
to the Institute of Advanced Study in Princeton and got one built for them.)

THE BOOTSTRAPPING ERA
COUNT ZERO INTERRUPT -- On receiving an interrupt, decrement
the counter to zero.

...

He's only had the Ono-Sendai deck for a month, but he already knew
he wanted to be more than some Barrytown hotdogger. Bobby Newmark,
aka Count Zero, but it was already over. Shows never ended this
way, not right at the beginning.

...

"You've probably seen one of these before," Beauvoir said, as the man
he called Lucas put the projection tank down on the table, having
methodically cleared a space for it.

"In school," Bobby said. ... "They used one to teach us our way
around in the matrix, how to access stuff from the print library,
like that..."

"Well, then," Lucas said, straightening up and brushing nonexistent
dust from his big pink palms, "did you ever use it for that, to
access print books?" He'd removed his immaculate black suit coat;
his spotless white shirt was traversed by a pair of slender maroon
suspenders, and he'd loosened the knot of his plain black tie.

"I don't read too well," Bobby said. "I mean, I can, but it's work.
But yeah, I did. I looked at some real old books on the matrix and
stuff."

"I thought you had," Lucas said, jacking some kind of small deck
into the console that formed the base of the tank. "Count Zero.
Count zero interrupt. Old programmer talk."

-- William Gibson, 1987
"Count Zero" (cyberpunk sci-fi novel)

( www.amazon.com/exec/obidos/ASIN/0441117732/hip-20 )

( project.cyberpunk.ru/lib/count_zero/ )

As I have studied the early history of electronic computers and
how they were programmed, one thing that stands out is how slow progress
seemed at first. Early models had their programs entered by connecting
patch cords like those used in the old telephone switchboards. The famous
"von Neumann Architecture" involved storing the instructions in the same
kind of memory as the data. The invention of the "assembly language" allowed
the use of mnenonics, little nick-names for the instructions like ADD
and JUMP instead of binary codes like 0101 and 0110. A special program
called "the assembler" converting the assembly language into the binary
codes, saving the programmer one step in the tedium.

After some false starts the concept of a "parameter" was developed,
a place to put numbers to be operated on, sort of like the "x"
in "f(x)", so that a sequence of instructions could be re-used.
The invention of "relocatable" code, which required "relative" jumps,
was another step in the direction of modularity. A new program
was created, the "loader," to load a relocatable program, later renamed
the "linker" as it was taught to thread bits of code together.
Then the idea of the "subroutine," which required a "call return stack"
got things really cooking. The the "interrupt" was invented, which
required a bit of saving and restoring partially done calculations,
but which allowed a computer to temporarily pay attention to a transitory
problem, allowing the programmers to express problems in a way closer to
the way they thought.

The eternal quest was for "a calculus of intention," a term coined
by neuroscientist Warren McCulloch, according to Paul Ryan in the 1971
article "Cybernetic, Guerrilla Warfare" in "Radical Software" v. 1 n. 3

( www.radicalsoftware.org/e/volume1nr3.html )

We're still not there, searching for the magic "DWIM" instruction
("do what I mean!") that would avoid this old lament:

I really hate this damned machine
I wish that they would sell it.
It never does what I want
Only what I tell it.

-- Men's room wall at Berkeley

But in those early days, the programmer was almost always the
electronic engineer who built then hardware. The creation of
a separate programmer job hadn't happened yet.

The engineers were used to tedium. After painstakingingly building
an electronic computer out of relays or vacuum tubes or even
transistors, the engineer would then painstakingingly program it,
often by toggling in bits on front panel switches. When paper and
magnetic tape storage of programs came along, they had less to toggle in,
just the "bootstrap routine" that taught the computer how to read in
a tape, allowing to "raise itself up by its bootstraps."

Something else that hadn't happened yet was the people programming
these computers had not yet realized how much of their time they
would spend finding and correcting their own errors, or "bugs."

In "The Airy tape: An Early Chapter in the History of Debugging"
Annals of the History of Computing, IEEE, Volume 14, Issue 4, 1992,

( ieeexplore.ieee.org/iel4/85/5016/00194051.pdf?arnumber=194051 )

M. Campbell-Kelly describes the discovery of a paper-tape relic consisting
of a draft (buggy) program written for the EDSAC computer in 1949, possibly
the first real, nontrivial application ever written for a stored-program
computer:

...the Moore School of Electrical Engineering organized a summer
school entitled "Theory and Techniques for Design of Electronic
Digital Computers," which took place during July and August 1946.

...

A number of computer programs were given by the lecturers on the
course for expository purposes, but the fact that they contained
some obvious errors caused no special comment because, like
typographical errors in a mathematical proof, they did not affect
the general principles involved. In fact, no evidence has yet
emerged that anyone had conceived of the debugging problem until
programs were tried on real computers. ... Nowhere in the ...
150 pages of ... reports [from the Princeton group] is the
possibility that a program might not work the first time it was
presented to a computer so much as hinted at. Consequently, there
was a surprise in store for the first group that completed a
digital computer and attempted to run a nontrivial program on it.
This turned out to be the EDSAC computer group, in the summer of 1949.

He quotes the original author of the first EDSAC program, Maurice Wilkes,
as he recalls his discovery of the error-correction problem in his Memoirs:

By June 1949 people had begun to realize that it was not so easy
to get a program right as had at onetime appeared. I well remember
when this realization first came on me with full force. The EDSAC
was on the top floor of the building and the tape-punching and
editing equipment one floor below on a gallery that ran round the
room in which the differential analyser was installed. I was trying
to get working my first non-trivial program, which was one for the
numerical integration of Airy's differential equation. It was on
one of my journeys between the EDSAC room and the punching equipment
that "hesitating at the angles of stairs" the realization came over
me with full force that a good part of the remainder of my life was
going to be spent in finding errors in my own programs.

The process or correcting the errors, or "bugs" in software was so new
that it didn't have a name yet.

WE'RE DEBUGGING IT
"I meant to do that."

-- Pee Wee Herman

There has been a bit of a flap as some ignorant bloggers have claimed
that Grace Hopper boosters credit her with inventing the term "bug" to
describe a problem, when that term dates back to 19th century
electrical engineering.

( www.xnetmedia.com/users/antibug/en/bug.html )

( en.wikipedia.org/wiki/Grace_Hopper )

According to her own account in Anecdotes, Annals of the History of Computing,
July 1981:

In the summer of 1945 we were building Mark II; we had to build it in
an awful rush -- it was wartime -- out of components we could get our
hands on. We were working in a World War I temporary building. It was
a hot summer and there was no air-conditioning, so all the windows
were open. Mark II stopped, and we were trying to get her going. We
finally found the relay that had failed. Inside the relay -- and
these were large -- was a moth that had been beaten to death by the
relay. We got a pair of tweezers. Very carefully we took the moth
out of the relay, put it in the logbook, and put scotch tape over it.

Now, Commander Howard Aiken had a habit of coming into the room and
saying, "Are you making any numbers?" We had to have an excuse when
we weren't making any numbers. From then on if we weren't making any
numbers, we told him that we were debugging the computer.

( cs.anu.edu.au/Student/comp2100/lectures/FirstBugCorrections.html )

What Captain Hopper actually deserves credit for is coining the verb
"to debug," an activity that definitely needed a name. It has long been known,
for example, that mathematicians work backwards from their conclusions
to their premises, and then publish the forward sequence as if that's
how the work was done. The work is already debugged when it is published.
Mathematicians seem ashamed of the jerky paths they followed to reach
their results, and usually don't share them. This attitude spills
over into engineering sometimes, where it is even more dangerous.
With machines, failure has a mathematics all its own.

Herbert Simon in "Sciences of the Artificial" (1969)

( www.amazon.com/exec/obidos/ASIN/0262691914/hip-20 )

provides a rigorous definition of "mechanism," but that definition
applies only to a machine functioning correctly, so that it matches
the model it is based on. The model breaks down when a machine fails,
needing to be replaced with a far more complex model of a malfunctioning
machine.

From a programmer's point of view, hiding failure is disastrous.
Many more things can go wrong after an initial failure that "hide
its tracks." There is even a programming principle, "fail early,"
which recommends grinding to halt at the first sign of incongruity,
before more damage can be done (to a database, or a robot, or even
a battleship).

The 10-hour drive to extract a zip archive which I described at the
beginning of this 'Zine could have been avoided if Microsoft's
programmers had followed the "fail early" principle more.

THE MAINFRAME ERA
"Dear God I am so bored."

-- inscribed by an operator on the NORAD SAGE computer,
(in use from 1962 until 1983), watching for a Soviet
nuclear attack that never came; on display at the
Computer Museum in Boston from the late 1980s until 1999

( www.smecc.org/sage_a_n_fsq-7.htm )

The funny thing about about "mainframes" is that nobody called them
that until they were obsolesced by minicomputers in the 1970s. We
just called them "computers."

I wrote my first program in 1967, at age 14, in FORTRAN, on a piece of
notebook paper, after reading a book about the language. It did long
division in decimal the way I had been taught in grade school. I wish
I still had it; I'd love to see how many bugs it has! The first
program I wrote that a computer actually RAN was in 1971, when I was 18,
in the ALGOL language, punched into cards for an IBM 360-30 mainframe,
for a college freshman programming class. We handed our decks through
a slot in a glass wall, and 15 to 120 minutes later got back a printout.
My final project for the class was a program that would play solitaire
with itself and tell me who won. When I found the card deck in my garage
a dozen years later, I fell down laughing at what a stupid concept that was.

But before all that I read everything I could get my hands on ABOUT
computers. Most of it was hogwash, anecdotes like "whenever it breaks
down we have to get that little red-headed programmer in here. She's the
only one it likes." Clearly the authors had no idea what they were
writing about. I learned that a computer could NOT RUN without software,
but not what software was.

Once I saw media critic Marshall McLuhan on TV and he was saying that
the biggest threat to privacy ever created was the computer. This
made no sense to me; I imagined a refrigerator-sized box wearing
sneakers and peeking in someone's bedroom window. Huh? (Of course
he meant that the ability to aggregate, sort and retrieve facts on
people quickly was a privacy threat, which I eventually realized many
years later.)

Finally I happened upon a book that explained it this way: a computer is
like a rail switching yard. There are zillions of side-tracks with short
trains of boxcars, each all black or all white. A little switcher engine
grabs these little trains one at a time and pulls them into a special
sidetrack called the "instruction register." Then a yard worker in a tower
looks down at the little train, and DEPENDING ON THE ORDER OF BLACK AND
WHITE BOXCARS, directs other switcher engines to move little trains of
boxcars around. And so on. Add an "arithmetic unit" to duplicate and
re-arrange some of the trains, and some I/O (input/output), and you've
got a computer! (It's even Turing-complete.) I got it, at about age ten.

Later in life I found studying the right comics to be a great way to
learn about computers. Richard L. Didday's "Finite State Fantasies" (1976)

( www.free-soil.org/tour/history.html )

and Ted Nelson's "Computer Lib/Dream Machines" (1974) come to mind.

( www.amazon.com/exec/obidos/ASIN/0914845497/hip-20 )

( www.digibarn.com/collections/books/computer-lib )

Studying Babbage's design for the Analytical Engine in detail is also
a great boon to understanding computers. (There is now a Java Applet
Emulator!)

( www.fourmilab.ch/babbage )

Babbage got his funding from the Navy, who wanted to automatically
print ballistics tables. When Grace Hopper found the dead moth
in the relay nearly a century later, it was still Navy money paying
for the computing machines, and with the same application in mind.

With the end of the war and the beginning of commercial uses of computers,
the new biggest funding source was insurance companies. They had
accumulated statistical information from all of their field offices
on millions of people's lifespans, and now wanted to use this hard-won
data to calculate aggregate actuarial tables.

The company that made the most hay in the mainframe era was, of course,
International Business Machines, founded by Herman Hollerith
right across the Susquehanna River from Vestal, NY (remember Vestal?)
in Endicott. As the Wikipedia article on IBM

( en.wikipedia.org/wiki/Ibm )

relates:

The company which became IBM was founded in 1896 as the Tabulating
Machine Company[8] by Herman Hollerith, in Broome County, New York
(Endicott, New York (or Binghamton New York), where it still
maintains very limited operations). It was incorporated as
Computing Tabulating Recording Corporation (CTR) on June 16, 1911,
and was listed on the New York Stock Exchange in 1916.

Again, Binghamton was the prototype for Rod Serling's "Twilight Zone."

And of course, the great software management classic, "The Mythical
Man-Month" (1974) by Frederick P. Brooks,

( www.amazon.com/exec/obidos/ASIN/0201835959/hip-20 )

was a product of the mainframe era.

Some of the culture of this time is also to be found in a humorous lexicon
inspired by Ambrose Bierce's sarcastic classic "Devil's Dictionary" (1881),

( www.amazon.com/exec/obidos/ASIN/1595479406/hip-20 )

( classiclit.about.com/library/bl-etexts/abierce/bl-abierce-a.htm )

called "The Devil's DP Dictionary" (1981) by Stan Kelly-Bootle,

( www.amazon.com/exec/obidos/ASIN/0070340226/hip-20 )

which gave us classics such as:

implementation - n. The fruitless struggle by the talented and underpaid
to fulfill promises made by the rich and ignorant.

infinite loop - see loop, infinite

loop, infinite - see infinite loop

recursive - see recursive

A lot of what I've learned about the mainframe era (besides my own
late-night ALGOL-coding sessions in the 1970s) came when I had many
opportunities to hang out at the Computer Museum in Boston in the 1990s
(alas now defunct). One thing I thought was cute was that when these
insurance companies got their brand new computers they needed to hire
programmers for them, but there was no such job almost no one with any
experience. So they put ads in newspapers for people with mathematics
degrees who also played chess, thinking this combination might do the
trick -- and apparently it did.

Another thing I learned, that I've thought about a lot since, had to
do with how the computers were programmed -- and debugged. There was
a console with a teletype, but that was for scheduling and monitoring
jobs. Programmers were expected to key their programs into cardpunch
machines and load the card decks into card readers connected to the
computer in order to run their programs. Typing programs in on the
console was possible, but frowned upon, because computer time was so
INCREDIBLY EXPENSIVE. But this was the favorite way for programmers
to debug their code, because they could make a change and re-run a program
quickly, speeding up the feedback loop between human and machine. Finally
management banned programmers from the console entirely, and hired special
"computer operators" who DIDN'T know how to program to run the jobs
and monitor them. But some of them SECRETLY learned to program, and
would sneak in debugging time, and so it went.

THE PESKY HUMAN FACTOR
"Mind in the loop."

-- motto of Mindtel Corp.

( www.mindtel.com )

Grace Hopper went on to help invent the language FORTRAN, short for
FORMULA TRANSLATOR, which was the first "high level" language.

( en.wikipedia.org/wiki/Fortran )

The story is told how her group got the first FORTRAN compiler working,
and tested it with their own programs, and then went looking for a
"naive user" unconnected with their project to be a guinea pig. They
taught him FORTRAN and had him write a program. He punched it
in and gave it to the compiler, which spit out an error: "Missing
right parenthesis." At this point this early "software developer"
asked a question that has never been answered to my satisfaction:

"If the computer knew what was wrong, why didn't it fix it?"

Without fail the "human factor" in software design has been the hardest
part to get right since the mainframe era. Having engineers even
think in terms of human psychology has been an uphill struggle, though
after the fact (and after Steve Jobs proved that good user interface
design can make you a billionaire) the "human engineering" approach has
been acknowledged as vital.

On several occasions I met an aviation pioneer named George Hoover,

( www.astronautix.com/astros/hooeorge.htm )

who claimed to have coined the term "human engineer" when he wanted
to hire a perceptual psychologist for cockpit design work.

When Walt Disney began designing the dark rides for Disneyland in
the early 1950s, he was able to hire aerospace engineers in the Los
Angeles area with "man-rated" experience working on aircraft cockpits.

Another famous "man-rated" device as the aircraft simulator with
motion base, which appeared in the form of the Link Trainer, in
Binghamton, New York in 1927. (George Hoover claimed the first design
was a failed attempt at a carnival ride, and it was HIS idea to make
it a trainer.) Today one of the early units is on display in the
baggage claim of the Binghamton Airport.

( en.wikipedia.org/wiki/Link_Trainer )

(Off topic: while I was working on this 'Zine the news had a story about
a laid-off IBM employee shot up an office in Binghamton. While searching
Google News for that story just now I found this one instead:

"Binghamton earns Tree City USA title"
News 10 Now - 2 hours ago
BINGHAMTON, NY -- Binghamton celebrated the designation of
"Tree City USA" for the second year in a row...)

I remember the first time I visited Rockwell International's Space Systems
Division in Downey, California (an LA suburb), which was where space shuttles
were designed and built, as well as the Apollo capsules before them.
The engineers took me into a giant hangar and showed me a huge wall that
looked like a sideways model railroad. Miniature grass, lakes, trees,
buildings, roads and such covered a wall dozens of feet high, forming the
geography of Kennedy Space Center at Cape Canaveral, Florida. A little
video camera on a 3-D XYZ gantry and tilt angles for roll, pitch and yaw
could "fly" over this wall and produce real-time video of what looked
like the actual cockpit view out of a landing space shuttle orbiter.

( en.wikipedia.org/wiki/Space_Shuttle_Orbiter )

A full-sized plywood mock-up of the orbiter cockpit had the instruments
in place, and TV screens for the windshields, showing the video from the
giant wall and interacting when you operated the cockpit controls correctly.
You could land it correctly, or crash it, depending on your skill.
It was in essence a simulator with an analog graphics system. So I asked
my escort, "Was this to train the astronauts?" No, there was another
simulator in Houston to do that. This system was built expressly and only
to test software the way it would be used in flight, with a "man in the loop."

That first visit was in 1983, working for a company trying to sell
Rockwell computer graphics system. Well, they bought a few, and later
I went to work for them programming one, which was kind of "instant
karma" since I'd designed the Application Program Interface (API).

While I got started experiencing the ramifications of my design decisions,
I got to know my neighbors in the aerospace cube farm, including two
ladies who were called "human factors engineers." They were really
good at answering questions like "what are the longest and shortest arms
you'll find on 90% of the American male population?" They also designed
animated humans for us to test in our computer graphics world of space
shuttles and space stations.

Well, that was the only job I ever had where we had human factors
experts by name on the payroll. (Oh, wait, there was a woman who
showed up a few months before a dot-com imploded who was supposed
to be a UI expert, but she didn't really do much.)

Instead we expect the engineers to be the human engineers as well.
My experience is that this doesn't work so well. Organizations
seem to excel at filtering out customer feedback, passing it through
technical sales and product marketing before it gets to engineering,
garbling all the way like a game of "telephone."

The attitude towards users ranges from the bug-eyed marketing guy
in Dilbert comics

( www.amazon.com/exec/obidos/ASIN/0740772279/hip-20 )

who, when Dilbert points out his new keyboard mock-up has no "Q" key says,
"You sound just like our whiney customers," to the movie "Tron" (1982)

( www.amazon.com/exec/obidos/ASIN/B00005OCMR/hip-20 )

in which the critters inside the computer have made belief in the
"users" a banned religion.

The fact is, the human is the most flexible and yet the least understood
component in the feedback loop between human and machine. All those
who insist software design must "logical" and "rational" miss this.
In my experience it is more useful for it to be metaphorical and
associative.

And though Moore's Law continues to chug along giving us exponentially
faster, cheaper, more powerful, lower-energy-using computers, the real
breakthroughs occur when we get new I/O devices, and those are
remarkably rare. In the early 1990s I did some research on the
origins of some common human-machine interfaces, and included it in
a paper I presented at the conference "Medicine Meets Virtual Reality II
-- Interactive Technology and Healthcare: Visionary Applications for
Simulation, Visualization and Robotics," January 27-30, 1994, sponsored
by UCSD School of Medicine. It was called "The Impact of Visual Programming in Medical Research.

( www.well.com/~abs/impact_vis_med.html )

Here is an excerpt:

...most types of computer input devices predate the computer itself,
and many date from the 19th century. The once-popular punch card
was developed in 1805 for the control of Jacquard looms. The
keyboard goes back to the manual typewriter, invented in 1829.
The joystick comes to us from the airplane, an 1890 innovation.
The buttons and paddles of today's video games are simply
electrical switches and potentiometers, understood since around
the 1820s. The audio speaker goes back to the 1876 telephone.
The cathode ray tube dates from 1855, and its use in television
is 1930s vintage. (In fact, so is the NTSC television broadcast
standard which we are still saddled with while government and
industry endlessly debate High-Definition TV). Even the high-
tech-sounding "asynchronous serial communications line" (as in
the still-popular RS-232 standard) and the near-universal ASCII
code (used for storing and sending alphanumeric text) both
originally come to us from an electro-mechanical device: the
teletypewriter . First invented in 1914, the old yellow-paper
"teletype" is still fondly remembered as the workhorse of
newspaper wire services, as well as for its more recent, somewhat
anachronistic use (well into the 1970's) as a cheap and reliable
hard-copy terminal for minicomputers.

In fact, I can only think of a handful of human interface
peripherals which were designed expressly for computers: the
light pen (almost never used any more), the track ball and its
upside-down counterpart, the mouse, the touch-sensitive screen,
the magnetic or mechanical 3D space tracker (such as those used
in virtual reality "data gloves" and "eyephones"), and a rather
obscure knob-like 3D positioning device called "the spaceball."
(Even futuristic eye-trackers, direct brainwave interfaces, and
electric field muscle motion detectors came first from the analog
electronics world.) It is easy to imagine that there are many
revolutionary human-machine interface devices waiting to be
invented.

MINICOMPUTER ERA
"Possibly the single most successful minicomputer design in history,
a favorite of hackers for many years, and the first major Unix
machine, The first PDP-11s (the 11/15 and 11/20) shipped in 1970
from DEC; the last (11/93 and 11/94) in 1990. Along the way, the
11 gave birth to the VAX, strongly influenced the design of
microprocessors such as the Motorola 6800 and Intel 386, and
left a permanent imprint on the C language (which has an odd
preference for octal embedded in its syntax because of the way
PDP-11 machine instructions were formatted)."

-- entry for "PDP-11" in "The Jargon File"

( www.catb.org/jargon/html/P/PDP-11.html )

In 1977, straight out of the redwoods of UC Santa Cruz, newly wed,
I took a job at a minicomputer manufacturer: Data General, in a
little New England town called Westborough, Massachusetts.

While driving east from California I read a book I'd come by somehow
that turned out to be the ideal introduction to my new job,
"Computer Lib/Dream Machines" (1974) by Ted Nelson.

( www.amazon.com/exec/obidos/ASIN/0893470023/hip-20 )

( www.digibarn.com/collections/books/computer-lib )

This amazing oversized book, as big as a "Whole Earth Catalog,"

( www.amazon.com/exec/obidos/ASIN/B001EPHEFY/hip-20 )

was actually two books in one: "Computer Lib," which sought to liberate
the "common man" from a fear of computers by offering a concise though
detailed and thoroughly understandable tutorial on the current state
of the art, and "Dream Machines," which offered a compelling vision
of the future of the human interface, including bit-mapped graphics,
smooth bit-wise scrolling, animated window opening and closing, and,
his greatest achievement, HYPERLINKS.

Upon arriving in Westborough we eventually ended up living at
1313 Summer Street, Apartment 13, with a second floor balcony that
overlooked the middle of town, a traffic circle (or, as the locals
called it, "a rotary"). Every Memorial Day the town fathers awoke
us at dawn firing cannon -- packed with powder, wadding and grass
clippings -- from the green at the center. I was reminded of an
old black-and-white TV show, "Window On Main Street" (1961),

( www.imdb.com/title/tt0054579 )

starring Robert Young of "Father Knows Best" and "Marcus Welby, M.D."
fame. I remembered it as about a journalist who moved back to his New
England home town to tell its tales. (Actually, it was set in the midwest.
Whatever.) Because of these flawed memories, it was a long-time goal
of mine to live overlooking the center of a little New England town.
So I got my wish, but it wasn't quite what I bargained for. Sure,
there was a certain segment of population that liked putting rooster
windvanes on their cupola roofs. But another segment, possibly larger,
liked breaking beer bottles on the headstones in the town cemetery.

But when I used my badge to open the security doors into the headquarters of
Data General Corporation, on an industrial park street called "Computer
Drive" (!), I entered a whole different world. Of course it had the
now-familiar fluorescent lights, acoustic-tile ceilings and cubicle farms.
Each cubicle had a teletype with yellow paper on a big roll producing
a constant hard copy record of all interactions with a timesharing
minicomputer in a machine room nearby. In college I'd had access to one
of these -- it was how I learned BASIC -- but I'd had to share it with
all of the other tens of thousands of students at the university, since
there was only one. But now I shared it with only one office mate.

(The eventgs by which minicomputers leapfrogged mainframes on the
technologies of timesharing and virtual memory is a story in itself.)

And the most amazing things in that building were the people: from all
over America and all over the world they came to DG, because the company's
annual hiring needs just for programmers exceeded the annual number of
computer science graduates in the U.S. I had entered the world of HIGH
TECH, where I would stay virtually uninterrupted for the next 30 plus years.

I met DG founder Edson de Castro in June of 1977 at an open-bar reception
for the new-hires, and -- with bravado from a Tequila Sunrise -- told him
he needed to get into personal computers and computer graphics in a big way.

"Nah," he said, and assured me, "They're both going to be a flash in the pan."

One of the first things DG did was to send me down the road to Southborough
where they built the hardware (BUILT THE HARDWARE!), where I took a class
in assembly language programming. In four years of information and computer
science classes I had never heard the phrase "assembly language," which
was odd when I think about it now since I took a class in parsers, a
fundamental building block of compilers, but is was so THEORETICAL (dealing
with a formal model called LR(k) parsers)

( en.wikipedia.org/wiki/LR_parser )

that the subject of implementation never came up.

But now I was surrounded by people who wrote assembly language code every
day, and I was tasked with updating the three main manuals used by those
programmers.

They taught me a lot technologically, but also I learned about their
subculture. It was during this era that I was first exposed to what
we now call "Colossal Cave Adventure"

( en.wikipedia.org/wiki/Colossal_Cave )

a text-only game that we just called "Adventure."

The main paradigm shift that occured when I was there was the
introduction of Cathode Ray Tube (CRT) terminals to replace the
teletypes. While it meant we no longer had an automatic log of
every session, it made new types of software possible, such as
"screen editors" instead of the old "line editor."

As it turned out, during the approximate era I was at DG, a writer
was camped out with a secret hardware development project I never
even heard about until later (it was that secret). Some keen insights
into the techies of the time can be found in the resulting book,
"The Soul of a New Machine" (1981) by Tracy Kidder.

( www.amazon.com/exec/obidos/ASIN/0316491977/hip-20 )

( www.cs.clemson.edu/%7Emark/330/soulques.html )

One of the things that impressed me most about DG at the time was
its excellent Quality Assurance (QA) process. When a product was
ready to ship a product board would meet, and hear presentations
from hardware, software, documentation and QA. The first three
groups would have to attest that they had finished their jobs and
done them right, and the fourth group had to verify the other three.
Then, after sign-off, the product would be publicly announced and the
company would begin taking orders. Nothing was ever "pre-announced"
at DG. (This was a company started by an engineer.)

Our fiercest competitor was Digital Equipment Company (DEC), up
the brain belt in Maynard, makers of the famous PDP line, and about
to introduce their new VAX line and become the defacto monopolist
in minicomputers.

But we still competed for mainframe customers too, and IBM knew it.
They brought out their own mini, the Series/1, which was an abomination
(personal experience).

To celebrate DG's tenth anniversary in business, founder Edson de Castro
had an ad drew up that, according to rumor, was refused by the industry
press. It said:

"They Say IBM's Entry Into Minicomputers Will Legitimatize
The Market. The Bastards Say, Welcome."

( oreilly.com/pub/a/oreilly/frank/legitimacy_1199.html )

Having just seen Star Wars (1977), I felt like part of the Rebel Alliance.

THE AFTERMATH OF THE GREAT UNBUNDLING
"Think!"

-- Thomas J. Watson

In 1969 IBM responded to an ongoing antitrust action by "unbundling"
its software; previously software had been "free" (or "bundled") with
the hardware purchase. Customers who had depended on IBM for all of
their software solutions now could -- or had to -- hire programmers
to write programs just for them. Thus began the first software industry
boom.

( en.wikipedia.org/wiki/History_of_IBM )

The second boom came only a few years later, when minicomputers
became cheap and powerful enough for many medium-sized institutions
to get them, including nonprofits and schools, often for small groups
of people to use.

Useful textbooks on programming began to appear. Inspired by the
English composition classic "Elements of Style" (1918,1958) by
Strunk and White,

( www.amazon.com/exec/obidos/ASIN/9562916464/hip-20 )

( www.bartleby.com/141 )

the marvelous "Elements of Programming Style" (1974) by Brian W. Kernighan
and P. J. Plauger

( www.amazon.com/exec/obidos/ASIN/0070342075/hip-20 )

is still useful today, even though it was written before objects
and has all of its examples in FORTAN or PL/I. It was followed by
"Software Tools" (1976) by Kernighan & Plauger,

( www.amazon.com/exec/obidos/ASIN/020103669X/hip-20 )

which introduced me to the charms of what I now recognize as the UNIX
shell environment, with its pipes, redirects and simple tools; it also
gave instructions on how to duplicate some of that environment when you're
stuck on inferior systems.

This book's concrete advice helped me save a FORTRAN project gone bad
that I was hired as a consultant to fix in 1985.

I mentioned before that Ada Lovelace invented the "go to" instruction in
a computer program. According to the King James Bible, the Lord saw the
tower of Babel and said "Go to, let us go down and confound their language."
In any case, according to then provocative article "Goto Statement
Considered Harmful" (essay, 1968) by Edsger Dijkstra,

( en.wikipedia.org/wiki/Considered_harmful )

the use of "goto" instructions in high level languages makes the code
difficult to read and therefore to debug. (These days we call it
"spaghetti code.") What replaces the "goto" are more structured looping
constructs such as "for/until" and "do/while" instructions. As K&P
said in "Elements of Programming Style" (op. cit.):

Everyone knows that debugging is twice as hard as writing a
program in the first place. So if you're as clever as you
can be when you write it, how will you ever debug it?

This was the beginning of a paradigm shift known as "structured programming."

In 1980 I saw a dramatic demonstration of its power by a colleague who
later became a friend, Bob B. who was at the time manager a group of
programmers at Datagraphics. Using a methodology called Nassi-Shneiderman
Diagrams, Bob had his team design each of their software modules visually
and share the designs with the rest of the team in a "structured walk-through"
before he let them begin writing code. (One guy admitted he wrote his code
first and then diagrammed it -- but after the design review in his module's
walk-through he had to change it!)

( www.edrawsoft.com/Nassi-Schneiderman.php )

The resulting software -- to operate a minivan-sized laser printer purchased
from Siemens Corp. in Germany -- had no bugs. It did run a few orders of
magnitude too slow. The Vice President of Engineering, a blowhard if I ever
met one, bragged that he would recode the whole thing in assembly language
itself to "save" the project (and throw Bob under the bus). But Bob's team
profiled the code, and found a few routines ate up all the time. Those were
rewritten in assembly language and performance became acceptable. (This is
straight out of K&P.) The result was easy to debug and maintain code. (Alas
it was never used in production because, after Bob quit, the VP of Engineering
put a toady in to replace him, who accidently deleted all the code while
trying to punish employees for keeping personal files on the computer.)

Somehow the process of software engineering takes the problems with
communications, egos, power struggles and culture wars that are always
present in engineering projects, and magnifies them while speeding them up.
One manifestation of this at the time was the struggle between proponents
of the languages PL/I and C. PL/I was designed by a committee to be all
things to all men and championed by IBM, and ended up being a bloated
abomination nobody could love, and as far as I know it is now a dead
language.

( en.wikipedia.org/wiki/PL/I )

C was designed by one guy for his own use and was deliberately kept simple;
it gained a popular fan base early on and remains in wide use to this day;
I have even been paid to write C code in the last year.

( en.wikipedia.org/wiki/C_(programming_language) )

This same guy, Dennis Richie, teamed up with three other guys to invent
UNIX at Bell Labs (back when there was only one phone company), again for
their own use.

( en.wikipedia.org/wiki/Unix )

As I have been telling people since the 1980s, UNIX will win because it
is the only operating system not developed by a hardware vendor trying
to meet a marketing deadline. In fact, because of its "state-sponsored
monopoly" status in telephony, Bell was prohibited by law from selling any
computer hardware, software or devices. They finally got an exemption to
sell UNIX to universities as "surplus" materiel, which is how it got to
Berkeley for the next phase in its evolution, being ported to the VAX
and becoming the Berkeley Standard Distribution (BSD).

Much of the culture of the minicomputer era is well-documented in
"The Hacker's Dictionary" (1996) by Eric Raymond.

( www.amazon.com/exec/obidos/ASIN/0262680920/hip-20 )

I'VE GOT THE PLIERS JAMMED INTO THE BOARD FRED
Spacewar! was a fairly good overall diagnostic of the PDP-1
computer and Type 30 Precision CRT Display, so DEC apparently
used it for factory testing and shipped PDP-1 computers to
customers with the Spacewar! program already loaded into the
core memory; this enabled field testing as when the PDP was
fully set up, the field representative could simultaneously
relax and do a final test of the PDP. Spacewar! was extremely
popular in the 1960s, and was widely ported to other systems.
As it required a graphical display, most of the early ports
were to other DEC platforms like the PDP-10 or PDP-11, or
various CDC machines.

-- Wikipedia entry on "Spacewar!"

( en.wikipedia.org/wiki/Spacewar! )

The minicomputer makers were mainly aiming to eat IBM's lunch in the
medium-sized business market, and they did, but they were also greeted
with enthusiasm by people who wanted to redefine the paradigm, expand
their minds and smash the state. These were people who emphatically
believed that personal computers and computer graphics would NOT be
"flashes in the pan." Ted Nelson, mentioned earlier, was proselytizing
about the mind-altering benefits of interactivity.

Douglas C. Engelbart and the researchers working with him in the
Augmentation Research Center at Stanford Research Institute (SRI),
in Menlo Park, CA, gave their famous demo in 1968, showing off
Engelbart's new "mouse" concept among other ideas,

( sloan.stanford.edu/MouseSite/1968Demo.html )

and continued in the 1970s to try to shift focus from Artificial
Intelligence (AI) to Intelligence Augmentation (IA) with computers.

The vanguard audio comedy quartet The Firesign Theatre were exposed
to a mincomputer (PDP-8?) running the popular psychiatrist simulator
"Eliza" over an acoustic modem connected to a teletype at a campus
gathering. People would type words into the teletype and Eliza would
respond with vaguely encouraging questions. It was a big hit at parties.

( en.wikipedia.org/wiki/ELIZA )

In the middle of the fun the Eliza program "crashed." The person playing
was confused by the system prompt, so the "techie" who'd instigated
this came over and typed a few commands to the operating system,
such as "SYSTAT" for system status, which returned something like:

SYSTAT: Uptime = 9:01; I have been awake for 9:32:47.
Log 5; 5 Jobs, Two Detached

When he was satisfied that everything was OK, the techie restarted
Eliza and the fun resumed.

The Firesigns were fascinated. The asked to take home the yellow TTY
paper at the end of the evening, and it became the first rough draft for
their album about a "Future Fair" which became known as "I Think We're
All Bozos On This Bus" (1971, comedy recording).

( www.amazon.com/exec/obidos/ASIN/B00005T7IT/hip-20 )

It contains this passage, when the hero reaches "Dr. Memory," the master
computer that controls the Future Fair:

SYSTAT: Uptime = 9:01; I have been awake for 9:32:47
Amylfax Shuffletime = less than 12% Freight Drain
Log 5; 5 Jobs, Two Detached
Minimum Entry Gate = 1
Total National Imbalance = 3456 Boxcars
Gate CLOSED.

( https://trac.ccs.neu.edu/trac/larceny/browser/tags/initial/larceny_lib/fortune.txt )

( pdp-10.trailing-edge.com/BB-PBDEB-BB_1990/01/10,7/system/systat.hlp )

Hardware hackers in colleges and universities built the first video
games such as "Spacewar!" using minicomputers. Because they cost less
than mainframes, it was easier to get permission to "mod" them (or it
was easier to get access, which was sometimes used instead of permission).
The first video gamers were sci-fi fans of E. E. "Doc" Smith's "Lensman"
series and wanted to experience spaceflight as he described it.

( www.amazon.com/exec/obidos/ASIN/0843959495/hip-20 )

In the wake of the "Summer of Love" the San Francisco Bay Area was a
wellspring of innovation in the early 1970s. One techno-utopian
group was the "Peoples Computer Company"

( en.wikipedia.org/wiki/People%27s_Computer_Company )

( www.digibarn.com/collections/newsletters/peoples-computer/index.html )

which sought to bring computer power to the people. If the secret to
social change was "Organize!" then maybe computers could help us do it.
A related project was the "Community Memory" project, which was the
first computer bulletin board system.

( en.wikipedia.org/wiki/Community_Memory )

Meanwhile, my friend Kim Levitt had moved to Washington, D.C.,
and was working for Housing and Urban Development (HUD) on a proposal
for an "information utility" that sounded a lot like today's internet,
with experiments in community bulletin boards as prototypes.

One embarrassing fact about these early democratizing experiments was that
they were ridiculously expensive. We were still waiting for Moore's Law
to make the computers cheap enough to be personal.

Many of these stories are told in "Hackers: Heroes of the Computer
Revolution" (1984) by Stephen Levy,

( www.amazon.com/exec/obidos/ASIN/0385191952/hip-20 )

( www.autistici.org/2000-maniax/texts/s.%20levy%20-%20hackers%20(full%20text).txt )

and "What the Dormouse Said: How the Sixties Counterculture Shaped the
Personal Computer Industry" (2006) by John Markoff.

( www.amazon.com/exec/obidos/ASIN/0143036769/hip-20 )

THE PERSONAL COMPUTER ERA
"There is no reason for any individual to have a computer in his home."

-- Ken Olsen, founder and CEO of DEC, 1977, who threatened
to fire anyone heard saying "personal computer" at the company

( www.snopes.com/quotes/kenolsen.asp )

In 1979 I moved back to California and continued to work with minicomputers,
as well as occasional mainframes, but I found ways to PLAY with the new,
almost toy-like, Personal Computers (PCs). This included the Altair
MITS with its 8080 chip and CP/M operating system, the Radio Shack TRS-80,
(we called it the "trash-80"), the Apple II (I bought one of these for
about $3000), the Atari 400 and 800, the Amiga, and of course the IMB PC.

One thing I learned during these explorations was that someone was
computer phobic, a good antidote was the old "Colossal Cave Adventure"
now ported from the minicomputers. This game came with virtually no
documentation. The only way to learn anything at all was to jump in
and make mistakes. And you couldn't hurt anything.

Here is a typical game fragment:

You are standing at the end of a road before a small brick building.
Around you is a forest. A small stream flows out of the building and
down a gully.

>enter building
That's not something you can enter.

>open door
You can't see any such thing.

>go in
What do you want to go in?

>building
That's not something you can enter.

>in
Inside Building

And so on. (BTW, the game is now available for on-line play.)

( jerz.setonhill.edu/if/gallery/adventure/index.html )

Every PC In played with had some kind of text-based command line interface,
even if it was brain-numbingly simple. Little operating system interfaces
like Control Program for Microcomputers (CP/M), Microsoft Disk Operating
System (MS-DOS), the Apple II's meager Apple DOS, Amiga's Command Line
Interpreter (CLI), and so on, required memorized key presses to accomplish
tasks like copying a file or running a program. In this way they were
similar to minicomputers with their CLIs and mainframes with their Job
Control Languages (JCL).

But what was new is that these little "toys" could display COMPUTER
GRAPHICS! It was slow, it was low-res, it wasn't always in color,
but it was GRAPHICS!

(Prior to this, for most of us, the word "graphics" meant using
a non-proportional-spaced printer such as a "Daisy Wheel" or "Golf Ball"
to print out a Snoopy calendar, with the picture of Snoopy made of
punctuation marks (what we now call "ASCII art").

( www.travelnotes.de/rays/fortran/fortran.htm )

Of course there was no internet back then, so we had to scrounge
information where we could. I bought books about my Apple II, and began
learning its 6502 assembly language. When my friend Bob S. got his first
Atari, he found a mimeographed "book" called "Des Res Atari" (Latin for
"concerning Atari") that revealed its secrets. I subscribed to a few
magazines, including BYTE and Creative Computing. After some good
reviews I bought a little language for my Apple II called "GraFORTH,"
a version of the FORTH language that did 3D interactive (monochrome
vector) graphics.

( hopl.murdoch.edu.au/showlanguage.prx?exp=7000&language=GraFORTH )

I'd done similar work in college on a goofball Burroughs mini, but now I had
it in my own den, and could stay up all night animating space shuttle landings.

I read an article in Creative Computing about a guy who worked at an
electric utility. Their mainframe had a database of the locations of
all the buried power cables in their jurisdiction, but it didn't do
graphics. He had an Apple II at home that did pretty good graphics,
but had tiny floppy disks and couldn't store the database. So he
connected them with a modem, and wrote early versions of "client/server"
applications, and was able to show where not to dig on his home screen.
He did it on his own time as a proof of concept, and wrote it up for
hobbyists after his bosses were underwhelmed.

I took notice, and thought this must be the architecture of the future:
data in a high-powered, centralized database on the server, and a local
graphics engine to manipulate a small portion of the data on the client side.
Today many programs, including the the popular application Google Earth,
use this same architecture.

TO BE CONTINUED...

CYBERNETICS ANNOUNCEMENTS
In 2008 two new books were published about Gregory Bateson: Jesper Hoffmeyer's
"A Legacy for Living Systems: Gregory Bateson as Precursor to Biosemiotics,"

( www.amazon.com/exec/obidos/ASIN/1402067054/hip-20 )

and Noel G. Charlton's "Understanding Gregory Bateson: Mind, Beauty, and the
Sacred Earth (S U N Y Series in Environmental Philosophy and Ethics)"

( www.amazon.com/exec/obidos/ASIN/0791474526/hip-20 )

Bateson of course was a founder of the science of cybernetics.

Also as of 2008 the Ross Ashby Digital Archive is now on-line.

( www.rossashby.info )

Ashby, of course, is author of one of the best textbooks on cybernetics for
beginners, "An Introduction to Cybernetics" (1964).

( www.amazon.com/exec/obidos/ASIN/0416683002/hip-20 )

The February 2009 issue of "The International Journal of General Systems"
is a special issue about "The Intellectual Legacy of W. Ross Ashby".

( www.informaworld.com/smpp/title~content=t713642931~db=all )

========================================================================
newsletter archives:
www.well.com/~abs/Cyb/4.669211660910299067185320382047
========================================================================
Privacy Promise: Your email address will never be sold or given to
others. You will receive only the e-Zine C3M from me, Alan Scrivener,
at most once per month. It may contain commercial offers from me.
To cancel the e-Zine send the subject line "unsubscribe" to me.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I receive a commission on everything you purchase from Amazon.com after
following one of my links, which helps to support my research.
========================================================================
Copyright 2009 by Alan B. Scrivener