Programming Without Computers

Mundane Pointless Stuff I Must Share (MPSIMS)
#1

I knew a man, once. His name is Bill. He’s Air Force, retired.

In the 1960s, he was a part of the ARPANET project, and in the late eighties, he realized that he was one of the men who helped create the Internet. And he told me a story:

When he became a Computer Programmer, he and about fifty other guys were in this enormous indoor office… everyone had his own desk. Cubicles haven’t been invented yet. And he seldom touched a computer – that was for the “keypunch” people, the “data entry” folks, who worked in rooms with refrigerator sized databanks, and tape reels the size of dinner plates, like in the old movies. He and the forty-nine other “Programmers” had a yellow legal pad and a can of pencils, and these were the only tools they needed.

Bill would sit at his desk, and think, and doodle equations on his pad. Eventually, a line of code would come to him, and he’d write it down. He’d look at it, work it out in his head, and perhaps erase it and try something else that looked like it would work better. Eventually, the line of code would be done to his satisfaction, and he’d lean back, and look at the ceiling, and think of the next line of code. And then repeat the process described in this paragraph. He would do this two or three times, every ten minutes or so. Once in a blue moon, someone would get up, take a pencil to the pencil sharpener, and return to his desk.

Fifty guys, in a room, doing this, all day long. At the end of the day, they’d hand all their scribblings over to the Keypunch people, who would actually enter the code into the computers. They’d get it back a day or two later if it didn’t work, and they were expected to correct it. If it worked, they’d take on new projects… for which they had to think up and write new code.

At the front of the room was the duty officer. He was the officer in charge. He sat at his own desk, and supervised the Programmers. While the programmers sat at their desks… and doodled on legal pads… and stopped to think… and stared at the ceiling … and chewed on their pencils… and doodled some more… and stopped and thought… and doodled some more…

One day at lunch, the duty officer finally snapped. “I’m going to request a new assignment,” he said. “I’m about to go crazy, doing nothing but watching you guys sit and doodle on your legal pads all day. And what’s worse, I CAN’T TELL IF YOU’RE GOLDBRICKIN’, OR NOT!”

#2

I’m pretty sure that’s not terribly far from the truth about how it was – although I don’t know anything specifically about how programming was done in the military.

Programming was done with pencil and paper and flowcharts. If you were trying to produce publication-quality documentation (or you were working in a very formal environment), you used a flow chart template to draw all the funny shaped boxes.

You might have written your rough-draft code on any old plain yellow paper, but before you sent it downstairs to the keypunch pool, you wrote it up all-so-neatly on coding forms which resembled graph paper. (ETA: Sample of COBOL coding form with some code written on it.)

The keypunch operators punched that into cards (if you were a student programmer doing your programming homework, you punched your own). This then went to the computer operators (if you were a student, you dropped off your deck of cards at the input counter). Come back a few hours later, or the next day, to get your output – this would typically be a printed listing of the program, showing all the compile errors your got (if any), or if no errors, then the output from actually running the program (which might have run-time errors), or else you might get an actual successful run with useful output.

Since you only got to run your program once every several hours, or maybe only once a day, you tried to get as much done with each run as possible. Today, you write a line or two of code at your terminal, run it and see how it works, then fix it or write a few more lines, rinse and repeat ad infinitum, until you have a running program.

Back in the bad old days, you tried to write as much of your program as you could before the first run. Or at least, you tried to write entire subroutines at a time. You wrote it, studied what you wrote, hand-simulated (“desk-checking”) a run with pencil and paper, and did as much debugging as you could before you even tried your first run. After keypunching it but before running it, you ran it through a lister machine that simply gave a printed list, and you sat and proofread that carefully. Finally, submit your deck to run. You wanted to get as much out of each run as possible. Rinse and repeat some more.

#3

When I got started we used coding pads to hand over to keypunchers. The computer was a hole in the wall. You put some cards and tapes on a shelf, an operator in the computer room would take them and come back later with some print out, and maybe more cards and tapes. To get to use a video terminal instead of punch card or teletypes was like stepping into a sci-fi movie.

#4

Punched tape for me. The punched tape readers were fun though. They would eat your roll of punched tape and spit it out on the floor, really fast. Then you’d have to find the end and laboriously wind it up. Hoping you don’t tear it.

#5

Your story was way before my time, but it sounds realistic to me…just change the year to 1981 and substitute 50 career engineers in a room for 50 students in a classroom ,writing Fortan commands to be keypunched.

But what I can’t understand is why the military would have a duty officer with zero duties.
For any team of 50 people, you need a good manager. And I’m guessing that the manager’s job in 1960 would have been to assign each engineer a tiny part of the program, tell him to write the equations and store the answer in memory cell X , then pass that answer on to the next engineer, whom the manager would have told to be working on the next step of the problem, starting with memory cell X.
Sounds like there would be a lot of conversations necessary.

But what do I know about 1960?

Now that is cool!!

#6

You could sit and think on a problem like “most efficient multiplication” or division or something…

So if they were desperately trying to do a maths lib, eg a floating point,
they might do it this way.
But the thinking time is highly variable, once they had the idea they’d then write down the page, perhaps taking a few goes to get it to the point they believed it would at least work, and send it in for testing… the idea being to test a number to get the most efficient algorithm for each function.
Main application writing doesn’t work so slowly, but optimizing mathematical algorithms does take go like that. The optimization could be in memory usage, since at the time memory was very limited…

#7

In January 1973, I took a mini-mester course in computer programming - FORTRAN IV. Since it was just a 4-week course, it didn’t get very deep. We’d make up a flowchart, figure out what the cards needed to read, then punch them out ourselves, pass them to the instructor who’d feed them into the reader, and wait for a printout.

It would be something like printing out the numbers 1 to 10, one per line with a blank line between. DO-loops, IF-THEN, other stuff I’ve long forgotten. It was a great introductory course, and we learned quickly that the commands and the cards had to be exact. Yes, it matters whether it’s a comma or a period… Good times!

I don’t know if I’d have made a good programmer or not - but understanding, even at such a basic level, helped me as an engineer, so there’s that. Ah, memories!

#8

My dad was a computer scientist in the '60s.
He almost never wrote code - he would work on algorithms (on his pad of paper, or blackboard), and then turn that over to coders, who would write the actual FORTRAN, and who would then have keypunch operators key it in.

So, the OP’s flow is missing a step.

#9

My experience was a bit later (learned to program in '66 while still a college student, became a “professional” programmer when I graduated in '69), and I have to say that my experience was different. I always keypunched in my own code, and the only use anyone I knew had for “keypunchers” was for entering large amounts of data - not programs.

The computer operator part I do understand - because I worked my way through college as a part-time computer operator. I was one of those gremlins who sat inside a mesh cage and to whom you turned in your decks of program cards. I’d run the cards in through the card reader, tear the resulting printout off of the printer, and place both it and your original cards in return trays that you could get to. And you had to be nice to your local computer operator or else your printout just might sit inside my mesh cage where you couldn’t get at it for an extra hour or two…

#10

To all the young’uns watching, THIS is why writing 50-100 lines of code a day was considered being very productive. :wink:

#11

One of the first thing you learned in a programming course in the '60s was how to make a drum control card, which you’d put in the card punch so that it would tab to the right columns for your Fortran program. Yes, I used Fortran coding forms, I might have some around still.

But I learned to program on a far more primitive system in high school - an LGP-21 from 1962. You punched your machine language program onto a paper tape using a Friden flexiwriter, then read it in, and ran it. 4 k of 32 bit words on a disk, no cores for this thing. Too early for ASCII. And when I say machine language, I mean machine language. The first assembler I used I wrote myself, based on a description in an IBM 1620 book. Labels and all kinds of fancy things, no macros though.

In colleges with batch processing real programmers worked at night when turnaround time is better. I suspect new CS students don’t keep later hours than any other students these days. When I TAed PDP-11 assembler, our machine had a card reader which had a queue of real cards. Lot of late nights there, especially just before due dates. Some of us TAs would stay up also, especially when bribed with Southern Comfort.

#12

Hell, writing 50-100 lines of code a day now is considered being very productive, to those that know.

#13

Bill wrote code. I have no idea what programming language he was using.

He told me the story, because he found it funny that in the real world and on television programs, a “programmer” is a human who sits at a computer keyboard with a pinched look on his face, rattling away on a keyboard.

In his day, a “programmer” was a muy importante dude… but he seldom, if ever, touched a computer, and the idea of a computer with a typewriter keyboard attached was Flash Gordon on the half shell… a PROGRAMMER used a PENCIL AND PAPER!

Everything else was for the keypunch peons…

#14

Didn’t know anybody coded anymore. Thought it was all drag and drop. :wink:

#15

Was he actually enlisted in the AF at the time? Most accounts I’ve read of early computer development had the military funding university and businesses to do most of the programming. I’m curious where there would’ve been rooms full of non-civilian programmers.

#16

Of course, you got plenty of zebra paper to doodle on - As a student, you handed in your boxed or rubber-banded stack of punched card to the operator. One or two days later, you got back your output on a stack of endless-paper from the line printer - a very thin stack if the job already failed with a mistake on the job control card, a thin stack if your job ran correctly, a somewhat thicker stack if you provoked a list of compiler errors, and a very thick stack if your job started running and produced a core dump - a hexadecimal listing of the entire contents of core memory.

#17

From what you describe I’m almost certain it was Fortran, with Algol as a possible second choice.

#18

Whippersnapper here to shoehorn my anecdotes into this thread. In college in the late 90s, we had to hand-write full page code snippets on quizzes. We also had assignments where we were allowed to enter the code into the computer, but we only got one shot at compiling and execution for our grade. The professor was very big on this concept. I’m not sure anyone cares anymore.

I dropped out of college and enlisted in the AF as a programmer. As Simplicio suggests, the system I was assigned to work on was developed in the late '60s by civilians but handed over to be maintained by uniformed (enlisted) programmers. This was in the early 2000s, mind you. We didn’t have to write code by hand (not sure how you’d even maintain a program that way), but we only had access to a compiler from our office via some dumb terminals. Once compiled, we had to go check out the software on an 8.5" floppy, drive over to a secured (underground) facility, and load it up on the classified test computer. Suffice it to say, stupid syntax errors were frowned upon.

Things are much better now.

#19

Now, some poor security analyst gets an email with a variable-size text attachment.

Ran perfectly? I get a 566-byte snippet. A bad JCL card returns about a page-long response, and problems in the code will be four pages or more.

At least it’s nearly instant instead of not all that long ago when reports would be printed and delivered overnight.

#20

For what it’s worth, I studied comp. sci. in the early 2000s and 90% of our coding classes involved no computers whatsoever. Final exams included. You just had to write good code and figure out its bugs on your own. As a trial-and-error black belt of spaghetti code-fu ; it was positively infuriating. Probably why I never got that degree :o.

But then, I understand the duty officer as well. I remember working as an assistant sys admin, regularly doing the rounds for routine maintenance and happening upon engineers busy flinging rubber bands at each other from behind cardboard forts, racing office chairs in their open space or air jamming to some prog metal jacked to 11. Every quizzical look was answered with an amused shrug and the sempiternal explanation : “Still compiling”.

I never figured out whether or not they were taking the piss.