Copyright Dr Alan Solomon, 1986-1995

Well, actually, not the *full* history of programming.  Just the bit
that I was involved in.

My love affair with computers started 21 years ago.  The first computer
I ever saw was a Pegasus;  she had 5000 valves and was the most
complicated machine I had ever seen.  With that many valves, the mean
time between failure was about an hour;  whenever they had something
critical to do, they changed all the valves first.  Storage was a
mercury delay line;  a tube of mercury with sonic transducers at each
end.  The sound waves took 50 milliseconds to travel down the tube, and
were then dynamically refreshed, just like a DRAM.  It was only a brief
visit, so I didn't find out what she could do, but I was so impressed, I
wanted one.  I spent the next two years building analog computers
(digital was out of the question, because of the high price of valves
and transistors).

A couple of years later, I went up to Cambridge to read Maths.  There
was an optional Computing course, and I signed up for it.  The nearest I
got to a computer was a teletype terminal, but I learned Focal, and
wrote a Bridge program with it (and several boring things like
Runge-Kutta).  One day, I managed to penetrate into the Computer Room
itself, with some Post-grads.  There I saw the Computer Itself - she was
an Atlas, and she was beautiful.  The operators had a six-inch VDU
screen running, and were playing a game on it called Spacewar;  two
small spaceships took pot-shots at each other across the screen.  I met
Spacewar again recently, on a PC, and it really is rather good (it has
been enhanced considerably, and it's in the user group library).  I
never got close to the Atlas again, but after seeing Spacewar, using a
teletype was pretty tame.

When I left university, clutching my new, shiny maths degree, I went to
work for Elliott Automation.  On my first day there, they showed me the
computer.  It was in a room on its own, and it wasn't doing anything.
They explained that all the engineers used it;  all you had to do was
put your name down on the sheet of paper.  Wow!  They gave me a little
project to do, which I was supposed to work out with algebra, but I soon
found a way to use the computer to solve the problem I was given.
Unfortunately, the Elliott 503 didn't use Focal.  It used Algol.  I
learned Algol out of a book in two days - it's that sort of language.
It seemed to think the way I did.  I wrote the program to solve my
problem, and punched it in on paper tape, using a Flexowriter
reader/punch.  I put my name down for a 1-hour time slot, and when my
hour came up, I had my very first taste of personal computing.  I was
the only one in that room - the computer was all mine.  I pressed the
button that loaded in the Initial Instructions, and that read a paper
tape called the Bootstrap.  Then the Bootstrap read a paper tape
containing the Algol Compiler, and then finally, I fed in my program.
The compiler spat it out, claiming that it had syntax errors.  Horror!
I rushed into the Flexowriter room, and commandeered a Flexowriter (the
custom was, anyone actually using the 503 could grab any Flexowriter).
I edited my program, by copying the tape up to the error, typing in new
code, then copying the rest.  I rushed back to the 503, and recompiled ,
and this time it worked.  But the program was too large for the memory
(the 503 had 8K of 39-bit memory) and I had to compile it to "own-code";
this involved the 503 punching a smallish roll of paper tape.

I then loaded a run-time Algol tape, and my own-code tape, and finally
my program ran, sending its output to paper tape, which I then printed
out on a Flexowriter.

The program didn't work, of course.  But eventually I got the bugs out,
and got my answers.  When I reported back to my boss, he wanted to see
my workings, to check my assumptions.  I told him there weren't any;  I
told him I'd solved it by getting the computer to test every single
possibility, and report those that worked.  "You can't do that!" he
said, horrified, "Go and work it out properly!"

I did, and got the same answers - it took me several days.  But I
learned a very important lesson.  If you solve a problem using an
unorthodox method, don't tell anyone how you did it.  and in particular,
if you use a computer to solve a problem, pretend you did it the hard
way.  For some reason, if you use a hammer and chisel to create a
statue, you are the craftsman, and not the hammer.  But if you use a
computer as a tool, a lot of people think that the computer is the
craftsman, and you don't get any credit.  This is a bit tough on the
computer, but they don't mind, you know.  Rather like faithful dogs, all
they want to do is help.

After a while, we acquired an Elliott 905 - it was lent to us as part of
a project.  And, oh glory, it had a line printer!  No more slow 5 cps
Flexowriters, now we could print at 100 lines per minute.  There was
just one problem.  The computer had a bootstrap, and operating system,
but there was no compiler, or even assembler, nothing.  The 905 just sat
there, unusably, frustratingly.  By then, I had become a regular user of
the 503 (we called it "the machine").  It was a real Personal Computer.
You were the only person using it, and you had to program it and operate
it yourself.  We used to fix it if it went wrong, too, or at least those
of us who were electrical engineers would.  It had a large box you could
attach with lights to indicate what was going on inside, called the
"Christmas tree".  There was a speaker that pulsed whenever the computer
executed a jump instruction, and you could tell what your program was
doing by the pattern of sound.  Someone programmed it to play Jingle

The division expanded, and computer time started to get scarcer.  The
Flexowriters were the main bottle neck;  there were only three, and they
were appallingly slow.  I found an old disused machine that would read
and punch five-hole tape (the Flexowriters used eight-hole tape).  I
rewrote my programs to produce output on five-hole tape, and from then
on, I had no problems doing my print-outs.  But we longed for that

Eventually, I could stand it no longer.  A careful reading of the
manuals revealed that it wasn't actually difficult to control the line
printer or to read a paper tape.  So I wrote a tiny program that would
read a character from paper tape, and send it to the lineprinter.  It
was assembler, and it was about 30 words of code.  I punched it onto
paper tape using a hand punch, got it working, and I had my own
lineprinter!  Unfortunately, you can't disguise the noise a lineprinter
makes, and soon everyone was using it.

The next project I did was voice recognition, and I needed something
much more powerful to do it on.  We came to an arrangement with someone
who had a 4/70 (made by ICL, I think).  But it didn't use Algol, it used
Fortran.  I found Fortran a lot harder to learn than Algol, and harder
to code.  The compiler was Fortran II, which has very little in the way
of modern control structures - no IF ...  THEN for example.  But the
output was direct onto a lineprinter - none of this output on paper
tape, then print up the tape on another machine.

I wasn't allowed anywhere near the computer - it was manned by someone
called an Operator.  He fed in my paper tape, rewound it for me, and
handed it back with my printout.  I though it was great having someone
else do the drudge work at first, but then one day, he dropped the
middle out of my six-inch-diameter roll of paper tape.  You've probably
never used paper tape, so I'd better tell you that this is absolutely
the worst thing that can happen to a paper tape.  But it is possible to
recover it, if you keep your cool and don't panic.  You put the centre
in a tape winding machine, and if you have it the right way round, the
twists from the centre dropping out are cancelled by the twists of the

He put it in the wrong way round, and the winding machine added to the
twists of the dropped tape, until the tape was totally ruined.  I
watched from outside the soundproof, locked computer room as this moron
wrecked days of work - he couldn't hear my screams or pounding on the
door.  And when he gave me back this useless mess, I grinned and
shrugged and said not to worry - if I'd done what I wanted and scragged
him, I'd have had a lot of trouble from him in future.  So I learned two
good lessons from this - the importance of backup (paper tapes are
clumsy, do you often let the previous version of a program act as the
backup), and the importance of hands-on computing.

Elliott was suffering from defence cutbacks round about then, and when
that project finished, there didn't seem to be much for me to do.  There
seemed to be no reason for me to stay, so I toddled off.

My next employer had a PDP-15.  It was more like a real computer - the
503 seemed like a toy by comparison (in fact, come to think of it, the
503 had about the same memory and I/O capability as a ZX81, except it
had no screen display).  The PDP had a 16K of 18-bit word memory, a disk
drive with a whole megabyte, four DECTAPE drives (a sort of fast
cassette tape holding 120K) and a line printer.  But best of all, it
used punched cards.  I loved punched cards.  If you wanted to change a
program, you could simply take some cards out and put new ones in.
Paper tape, on the other hand, you had to make a whole new copy, or else
use a hand punch and splicer.  I kept all my programs on punched cards -
I never fully trusted the DECtapes, although they were perfectly
reliable, and quite fast.  The trouble was, with paper tape cards you
could *see* your data;  with DECtapes it was an act of faith that your
precious program was there.

The PDP was another single-user computer - only one person could be on
it at a time.  So again, I was using a personal computer.  You could
also set up a pack of cards for the operators to run for you, but you
only did that for production work.  Programming was done on-line;  you
read the pack of cards into the machine, and compiled, linked and ran.
If it didn't work, you commandeered the card punch and changed a card or
two, or else you could edit the source on disk.

DECtapes were quite fast, compared to cards and paper tape, but quite
fast isn't fast enough.  We discovered that if you wrote onto every
fifth block, the tape could just stream non-stop, whereas if you wrote
onto every block, it had to go back and forth to read a file.  At the
end of the tape, you turned around and started writing backwards on
every fifth block, and so on.

But the disk was the fastest.  We kept the system on half of it (KM15, I
think it was called) and used the other half as a scratch area.  To get
the fastest speed, you would read an entire DECtape onto the disk in one
go (up and down the tape five times) then get your programs and data
from the disk.  I also wrote my own disk handler, using double buffering
and sector interleaving to extract the maximum performance from that
disk.  I remember that it rotated once in 50 milliseconds, and a lot of
our software used that fact to optimise disk performance.

The other nice thing about having a disk was that you could swap bits of
your program in and out of memory.  That's called overlaying, but we
called it chaining, because the overlay generator was called CHAIN.  We
had 8K of memory for our programs (the resident operating system took up
the other 8K).  Part of that would be taken up by the device drivers (we
called them handlers).  There were six different handlers for the disk,
and the main difference was the space they took up.  The biggest one let
you read and write, and have three files open at once.  The smallest one
let you open one file, for read access only.

We programmed in Fortran, with bits of assembler when we needed extra
speed, or needed access to the hardware at a low level.  We also had
Snobol, a string oriented language, which we used for doing labels for
mailshots.  It was good fun, trying to squeeze your program into 8K of
memory, but eventually we persuaded the powers-that-be to let us expand
the machine (we called it "the machine";  I thing computers are always
called "the machine").  Memory cost a pound per word, and we got
permission to spend #8000.  A great debate ensued, whether we should buy
8K of memory, which would put the memory up to 24K (and so doubling the
usable memory) or 4K of memory and a second disk drive, giving us 1 1/2
megabytes instead of 1/2.  In the end, we got 8K and the extra 1
megabyte of disk as well.

You really can't imagine the feeling you get when you've doubled your
memory and trebled your disk space.  Suddenly, we could do things that
had been impossible.  It was round about then that I invented the
overnight run - there were about 14 hours overnight that were completely
unused, compared with 10 hours during the day, which were being fought
over.  I'd tried an overnight run on the Elliott 503, but the problem
was that the tape punch spewed paper all over the room, and would almost
certainly jam during the run.  On the PDP the problem was that we
couldn't run the lineprinter at night, or the people in the flat next
door (yes, there were people living in the flat next door) would
complain.  But with our new disk, all we had to do was write the output
to a file, and print it up the next day.  Shortly after that, I invented
the weekend run (60 hours of pure computer time).  I got into deep
trouble one sunny bank holiday weekend, when I did a 100 hour run, and
the air conditioning failed in the middle.  The computer overheated, and
stopped working, and when I got in on the Tuesday after the bank
holiday, I had a lot of accusing fingers pointing at me.  But after we
opened the windows and repaired the air conditioning, and got the
temperature down from 120 degrees to a more normal 50, the computer
worked fine.

As we used the PDP more and more, we began to run into severe arguments
about priorities - there simply wasn't enough computer for all that we
needed to do.  I was one of the worst culprits - I computerised
everything in sight.  One day, I asked the post room to take me off all
the magazine lists I was on, and circulate me a completely different
set.  They said they couldn't do that.  They had a list of readers for
each magazine, and would have to go through the entire list searching
for my name.  This explained why magazines continued to come round for
people who had left two years ago.  I wrote a relational database
management system (nobody told me you could buy them;  perhaps you
couldn't in those days), then wrote a magazine circulation system.
Magazines were circulated to a list of numbered job functions, and each
person was assigned one or more of these.  So if someone left, his
number was made blank, and if someone changed jobs, you changed his
number.  You could print a list of magazines, and who read each one, and
you could print a list of readers, and which magazines he read.  It
printed sticky labels for the circulation, and if at the end of the
quarter, a magazine had a lot of labels left over, you knew that it had
stopped coming in, and the librarian could chase it up.

The whole database was kept on punched cards, because I decided that the
librarian would be very comfortable with those.  In fact, the system
survived through several changes of librarian, and even survived my

Of course, that wasn't the only thing I did.  That was a three-day
project, in fact, but the pay back was that I got the magazines I wanted,
and got them faster.  The company saved one person's salary (actually,
what happened was that the librarian's assistant was able to do much
more useful things, instead of doing nothing but handle the magazines).
But this was a perfect example of a highly leveraged project, where a
few days of my time and a bit of unorthodoxy was repaid hundreds of
times over.  It is typical of most computer installations that the DP
people give the users some parts of what they ask for, instead of going
out and actively seeking highly leveraged projects.

I did a lot of things like this.  I would find some poor soul beavering
away on something that the computer could do easily and in a flash, and
I'd explain it to him.  He'd not understand, of course, and he certainly
wouldn't be interested.  And he'd probably be too busy, to, because his
job involved him spending so much time beavering away - you see the
problem?  Nobody could approve the project, because the user didn't want
it, and the user didn't want it because he couldn't see the benefits,
and he couldn't see the benefits because the program didn't exist, and
the program didn't exist because nobody could approve the project.  A
complete circle.  Most people can't see any way out of that circle, but
actually, it's easy.  You just do the project, without approval, when
you're supposed to be doing something else.  Then, when you have a
semi-working program, you show it to the poor beaver, who (if you were
right about what he needed) would leap up and hug you and ask why nobody
had ever told him that this was possible.  So now you had an Official
User Request, you could get the project approved, and in the time that
you were supposed to be spending on the project, you were actually just
polishing it up, and the real work was on the next leveraged project.
My managers never found out why I was so popular with the users, and so
good at getting them to ask for useful programs.

Eventually, technology moved on, and we began to think about replacing
the PDP.  I think we made a major mistake, then.  We had to decide
between an HP 3000 and a VAX, and we got the HP.  At the time, I was too
busy playing with my beloved PDP to try to affect the decision.

The HP3000 was a nice machine.  The nicest thing about it was that it
was a multiuser machine, running MPE (Multi Programming Executive).  Me
and a friend spent weeks learning the machine, so that we could hack
into each other's accounts and leave little surprises.  Eventually, I
got complete control of her account, and was able to restrict her access
in all sorts of annoying ways.  Then she got into my account, and used
that power to lock me out of the computer, and it was days before I got
back in.  Eventually, we declared a truce, but in those weeks, we
learned an awful lot about MPE.

I was wandering around that system one day when I found a very
interesting file - it had several account names and what looked like
passwords.  One of the accounts was "Field Service", which had full
System Manager privileges.  Using that, I asked the computer to print
out every user account and password on the system.  I also created
another account, with System Manager privileges, for later use - this
one I didn't print out.  Then, one evening, I left the printout on the
DP manager's desk.  The next morning, I watched him go into his office.
There was a short silence, then an explosion.  I let the explosion
continue for about an hour;  I felt quite annoyed that he hadn't
immediately realised who had done it.  Then I stuck my head up and asked
it he'd got the printout I sent him.

He wasn't at all grateful for showing him the hole in his security - not
at all.  So I decided not to tell him about the extra System Manager's
account I'd created.  He never did find out about it, and for all I know
it is still there, waiting for me to come back.

The HP3000 used VDUs as terminals.  I'd never used a VDU before, and
this was a far cry from the six-inch circular CRT display on the Atlas.
You could immediately see the potential for games like Spacewar, but
there was a game on the HP3000 that made all others look silly.  This
game was called Adventure.

I guess a lot of you will have played Adventure.  It was written in 1971
by Crowther and Woods, and it is set in the Colossal Cave, where dangers
lurk, but treasures can be won by the lucky and quick-witted.  There's a
version on one of the user group disks, and there are several bulletin
boards that will let you play it on-line, using a PC version that I
wrote.  The significance of Adventure was that it was the first time I'd
ever met a user-friendly computer package.  You could type HELP, and it
would explain things.  If you made a syntax error, it would say "I don't
understand that" instead of something like "User error 4386YW - REDO".
It understood synonyms;  you didn't have to get things exactly right.
The whole thing gave the impression of being designed for people, not
just computer experts.

I was instantly converted.  I spent a lot of time playing the game -
probably more than 500 hours until I had completely solved the whole
thing.  But I was also converted to this way of writing programs;  this
was the style of program I wanted to use, so it would also be the style
of program I'd write.  I started writing my programs in the first person
singular;  that program was really me talking to the user, so it used
words like "I" and "me" and "sorry".  I wrote help screens, again taking
Adventure as my model, that explained things simply and concisely and in
plain English.  I got into a heap of trouble with management, of course,
who called my style "noddy" and "condescending", but the users seemed to
like it, and that seemed more important to me.  So sometimes I'd do two
versions, called "standard" and "novice", and show management the
"standard" version.

My language was still Fortran, but now it was Fortran IV, with the
improved readability of IF ..  THEN statements, and more flexibility in
formatting.  I was pleased to discover that Adventure was written in
Fortran, too.  It seemed to me that there was little point in using
anything else.  Real Programmers did it in Fortran.  Cobol was for noddy
business applications like payrolls, and I didn't want to get involved
in that sort of thing.  Algol was my true love, but there didn't seem to
be many compilers around.  Assembler was something you did when you had
to, to speed up something critical, or to get better access to the

I worked hard, and converted all my PDP programs to the HP3000.  By the
time this was done, I'd solved Adventure, and I started looking around
for new challenges.  The DP department started to close up the HP3000,
putting all sorts of limits on what you were allowed to do, and how much
disk space you could use.  Worst of all, they stopped allowing us into
the computer room.  It's difficult to explain, but there's something
very unsatisfactory about using a computer you never actually touched.
One day, they bought a floppy disk drive, and it just sat there for
months, because no-one knew how to program it.  They wouldn't let me
near it to see what I could make of it, and I don't think it ever got

The HP3000 was a nice machine with a friendly operating system.  But it
was the first time I'd shared a computer with other people, and when
someone did something that was CPU intensive, the whole system slowed
down to a crawl.  At first, it wasn't too bad, because we all knew what
everyone else was doing, and we were all in the same room, so we could
throw manuals at the offender and make him stop.  But they hung more and
more terminals on the machine, and eventually, the machine would get
very sluggish every day at 11 a.m.  and 3 p.m.  This got worse and
worse, and eventually the system became almost unusable sometimes.
There didn't seem to be any way round this except by adjusting people's
priority.  Naturally, the users got the lowest priority.  Eventually, I
decided it was time to move on.

Next time, I'll tell you about the user-hostile Univac and its cryptic
operating system which put me off Sperry for ever.  Also, another
encounter with a PDP with a multi-user operating system, and then, that
jewel of creation, the VAX.  After the VAX, I'll tell you how I met a
ZX81, had a flirtation with a Spectrum, a more serious affair with a
BBC, a brush with a Rainbow, and finally formed a lasting relationship
with an IBM PC.