How did people deal with punch cards? | Hacker News Reader

How did people deal with punch cards?

blog.computationalcomplexity.org

168 pointszdw183 comments

People complaining about punch cards? I started programming with optical mark cards which were much, much worse. I'd fill in bubbles on each card to make the program, mail the program to the Waterloo computer center, and get my output back in a week or so. After fixing the errors (either the bubble wasn't dark enough or a coding error), I'd send the program back. It took me weeks to get my first program to run. Compared to that, punch cards were like living in the future.

By the way, if you want to experience punch cards in person, come to the Computer History Museum (Mountain View, CA) on Wednesdays or Saturdays for demos of the IBM 1401 and the opportunity to punch your own cards. You can also see a high-speed card sorter in action.

Ah my dad has the same story about his time in the Math and Computer building at UW. Though he said it got a lot better in later years when he could just show up at 4am and run things pretty much right away because nobody wanted to be there at 4am. That part I find hard to believe based on my time at UW.

When you talk about the MC building at UW, you have to mention the Red Room. see https://cs.uwaterloo.ca/40th/images/img039.jpg and https://ist.uwaterloo.ca/cs/redroom/

The central core of the first floor of the building was for the mainframes and supporting gear in the Red Room. The second floor had windows which let people look down on the mainframes and the priests tending the electronic behemoths.

the Red Room definitely had a Stanley Kubrick The Shining vibe to it.

> fill in bubbles

Sounds like scan-tron testing, don’t forget your #2 pencil!

Probably an HB pencil - Commonwealth countries tended to use a different hardness measure for pencils than the US. I think Waterloo is a Canadian university.

Am Canadian, never heard of a #2 pencil but very much had HB pencils

Woah, TIL that HB was not a branding mark on the #2 pencils I used growing up!

HB is the middle of the scale. From there it's going both ways. Hs are harder and Bs are softer. There's also an F thrown into that scale for extra confusion.

https://pencils.com/pages/hb-graphite-grading-scale

I just love these ancient programming war stories!

There was a very LARGE sign on the printer 'DO NOT PUT YOUR CARDS ON THE PRINTER' and once a day, someone would put their cards on the printer, it would run out of paper, and automatically open up for more paper... scattering the cards to the wind. I would only spend one day punching a week, so as to avoid saying..."You have a printout... just start sorting by hand, and then put a red mark diagonally down the top... My father used cards too, and his decks became Christmas trees.

My dad told me you were supposed to make a diagonal line across your cards with a magic marker incase that happened so you could put them back together.

My first year in college was the first year they didn't use punched cards at my college.

> come to the Computer History Museum (Mountain View, CA) on Wednesdays or Saturdays for demos of the IBM 1401 and the opportunity to punch your own cards

My wife and I went to the museum yesterday and indeed got to punch our own cards! It was a super cool experience, thanks for recommending it!

From the moderator at OEIS [Incidentally, today these cards are sometimes referred to as "punch cards" (sic). This is wrong, they were always called "punched cards". Anyone who says "punch cards" is showing they know nothing about the subject. Saying "punch cards" is like saying "hike boots" or "walk stick" or "chew gum".]

I will apologize for speaking of them as "punch cards" to the first person who shows up with a black eye caused by a blow from a "punching bag".

Penciling cards? How about straight binary input through frontpanel switches?

My first PC - a Heathkit H8 - had a numeric keypad that could be used for loading RAM contents with a program and starting execution at some address. I don't recall if it was decimal, hex or octal but it was a lot more convenient than the IMSAI at school that had a bank of paddles to set 1/0 to load into memory.

But my first encounter with computers was Fortran on an IBM fed with punch cards. Very unforgiving. No backspace. And local jerks would slip already punched cards into the feed hopper so those had to be checked before punching any cards. And the error messages were absolutely opaque.

> I don't recall if it was decimal, hex or octal

Worse - it was split octal. "the memory location after 000.377 was 001.000." https://en.wikipedia.org/wiki/Split_octal

But yeah, better than toggle switches.

In the snow, too.

Uphill in both directions.

My father — now in his 80s — claimed he had to walk "uphill, both ways, to school" in front of my grandfather; my grandfather quipped: "there was a whole hill between the house and the school: I kept telling you boys to go around it!"

To be fair, this is possible. My school was on the other side of a fairly steep valley and each way if I went by bike the ride involved an exhilarating initial descent and then an exhausting uphil slog.

I started programming around 1967-1968. In my high school, there was an old keypunch machine used for school administration purposes. I had a friend that was able to submit any program I keypunched to the school district's IBM computer; I never saw the computer but it's likely that it was something like an IBM 1130. My my friend would bring the output back a couple of days later; so fixing even one typo required a few days.

This old keypunch machine was a model 026, not the much nicer model 029 that was ubiquitous while I was in college. The 026 had a very basic keyboard, see [1], one could punch the columnar code for the upper case letters and numerals along with a handful of symbols: #@,%$./ and space. This isn't enough to even program in early FORTRAN, the language I was trying to use.

To type say an equals sign one had to use the multi-punch key that allowed punching a combination of the basic symbols that would properly encode the equals sign. It was slow going. One mistake and the card (corresponding to a line of code) was ruined and had to be redone.

I had just finished reading a book on solving linear programming problems, which come up often in operations research, using the simplex algorithm (I still have this book too). Naturally, I decided that that would be the first program I ever wrote. That definitely wasn't the best "hello world" program to try first. I wish I still had a listing of that program; it would be good for a few laughs.

The first working program I wrote printed out a table of sine and cosine values for angles from 0 to 90 degrees. The rest of my programs in high school were not much more sophisticated. I was just trying to learn it on my own as a hobby. I still own my book on Fortran that I bought with my newspaper route income back then, McCracken's book on Fortran IV [2].

A couple of years later I got to write more serious programs and used the IBM 029 keypunch machines that were a lot better. Programs got long enough (hundreds of lines!!) that card management became important. Sturdy cardboard boxes or even long metal drawers designed for holding the stacks of cards were the main tool for source code management.

In college, I was able to use IBM's data processing equipment for punching line numbers in columns 73-80 on each card (these columns are ignored by FORTRAN IV); this allowed dropped cards to be sorted back into order through a series of passes (one for each digit of line number) on IBM card sorting machines. This was my introduction to radix sorting, [3].

One complication when numbering cards was inserted new code between existing cards. Because of this, my initial punching of line numbers in columns 73-80 had to be done with gaps, usually I'd leave one or two zeros at the end of each card number. However, to get the auto numbering machine to do this required pulling out a large (1 foot square) plug board from the equipment and physically connecting jacks with switchboard like cables to make the equipment count by hundreds and punch in columns 73 through 80.

It was all quite primitive. But one did learn to review code carefully before submitting it for being run.

Grad school was better, I still frequently used FORTRAN punched on cards, but I was also able to use the mainframe in a timesharing environment where I used TECO as my text editor at a terminal, there must have been around twenty of these terminals connected to the CDC 6400, [4].

[1] http://www.columbia.edu/cu/computinghistory/026-keyboard.jpg

[2] https://archive.org/details/guidetofortraniv00mccr

[3] https://ibm-1401.info/KensSorter/type83-a.jpg

[4] http://www.bitsavers.org/pdf/cdc/cyber/cyber_70/kronos/60407...

When you program FORTRAN with punch cards, does the computer run the program and provide the output, or is there an intermediate step of having the compiled executable output which you then need to feed back into the computer?

Note, I never actually used punch cards, but they existed when I was in college. The user interface was like this:

1. You prepared you cards, offline using a punch machine.

2. You got a form from the computer center and filled it in with various details for your job.

3. You wrapped the form around your card deck, secured with a rubber band and placed the assembled package into a box/shelf in the entrance to said computer center.

4. You went about your business for a day or so.

5. You checked your pigeon hole outside the computer center, or perhaps your department mailbox.

6. Eventually your card deck would show up there, accompanied by a line printer (fanfold) output that was whatever your program printed when run.

There were more complex workflows allowing things like tape input/output where you'd specify the tape label either on the form or in the deck.

This is where "Job control language" (JCL) comes from -- a scripting language to facilitate running batch jobs. The precursor to Dockerfiles and Github Actions YAML.

IBM JCL was where the truly magical incantations entered the picture. We had grad students who hung out in the punch card room and they were the go-to guys for getting your JCL sorted out. SYSIN DD *, baby!

Back in the Usenet days, I saw some greybeard's .sig line:

\\GO.SYSIN DD *

DOO DAH

(Checks beard color and blushes.)

I used to know some jcl, those were the days. It was used in a few "advanced" classes when I was an undergrad. Was that the one that had the little hello pamplet with details, or was that yellow pamplet describing sys/360 assembly.

I've also never used punch cards, but I had seen the equipment in the computer lab at university.

One more trick for the young ones here that I've heard is: With your completed stack of punch cards, take a marker and make a diagonal slash across the edge of the stack from top to bottom. That way, if you accidentally dropped the deck of cards, you could put them back in at least the approximately correct order very quickly. You would still want to look through the cards one at a time to ensure the order, but the process goes much quicker if the deck is nearly sorted.

I mostly used serial terminals connected to minicomputers like various PDP-11s and Dual VAX 11/780s. I did get to experience the joy of trying to complete an introductory CS assignment near the deadline. The machine slowed to a crawl, but didn't crash. You would type in one character, and wait for it to appear. We were warned to submit our assignments early!

I'm sure it was possible to punch the compiled executable as an option, but I was a student during most of my keypunching days so the cards would be read by a card reader the computer would compile the FORTRAN and then execute the program, reading input data from cards that were stacked behind the source code.

One summer, I worked at an engineering firm and had to run a program frequently on a set of input; it's possible that the executable I was loading into the card reader was already compiled and not the original FORTRAN source, but I don't remember for sure.

Typically, at my school, the decks were standalone. They included the program, the data, and any control cards (like actual commands).

For a COBOL class, your deck was the commands to compile and execute the program text that followed, and then that program operated on the data cards that followed the program cards.

Then, your output would likely be the compilation listing, followed by whatever output your program created.

Mind, this was school, and these were student programs. And while you could wrap up your deck and drop if off at the computer center to be run, it was likely better to take it to the lab to that had the RJE (Remote Job Entry) terminal which had a card reader and a line printer.

Jon’s submitted there would print out on the line printer, but the printer could be used by others as well, so there was typically a queue of printouts that you had to wait for. But in general, the RJE lab had the fastest turnaround.

I remember my friend playing Lunar Lander. He had the Fortran source code, and would add a new burn card, and run the deck through. He’d go over the output, add another card, and run it again. This was the process, but not necessarily an efficient use of paper.

Now, there were also folks that were not programmers, but rather students and professors using tools like SPSS (a statistical package).

A student assignment deck was typically 1-2 inches thick. Not much code, not much data. But these researchers, they had decks measured in feet. They’d carry them around using small carts and hand trucks. The cards were in cardboard trays. Most of that was data. Largest set I saw was probably 10 feet long of cards.

They took their sweet time being run through the feeder. Just grab a chunk, and put it in. As it fed, pile on some more. No rush, it’s an input device, it’ll wait for more cards as you moved the read cards out and fed more in. But it was an endeavor.

Generally, you'd have a deck of cards consisting of JCL, FORTRAN, and data. Your first cards were usually something like $ACCOUNT (for billing) and $JOB (for identification), the program code, then //DATA and the data. You would submit this deck through a card reader using RJE (Remote Job Entry) to either a HSJS or a GPJS (high-speed or general-purpose job streams respectively, depending on your account) on the one computer shared by the entire campus where they were batch-processed and the results sent to a high-speed line printer near your card reader. On good days this would take seconds. On the morning a first-year assignment was due there would be a lag of hours.

There was no 'compiled executable'. There was 64k of core memory and no disk for HSJS jobs. There was just you desk of cards and the resulting printout and everything else was ephemeral.

There were “student job” compilers that ran the program from the cards and printed the output. I don’t know how the machine and compiler did this. Probably by compiling to memory and executing said memory.

At the University of Maryland in the late 70s we put the FORTRAN program on punched cards and wrapped some sort of batch language around it all to compile and run it -- as I recall -- has been a long time -- then output was on fan-fold paper that the operators provided back -- UNIVAC 1100 series -- also as I recall. When I discovered ASR 33 dialin terminals it was heaven in comparison.

Depends on the system, for many it was possible, more often you could leave a binary on disk (or tape)

> But one did learn to review code carefully before submitting it for being run.

My first experience of coding was COBOL. I was expected to use a pencil and a coding sheet; my efforts were then reviewed by a human, before I was allowed to submit it to a compiler.

Amazing they didn’t just leave a space on the card for a jump operation of some sort. When you want to add something to your program or fix an error you just use the space to say “jump this many forward” and resume. I guess there is a good reason something like this was not possible?

Probably not possible because it wasn't thought of when the system was first implemented and introducing such a change would involve getting new hardware with the jump feature and quite probably new hardware both to read the new card format and to produce the cards themselves. And everyone else also having to do so given the dominance of the IBM 12/80 card format.

At least cards didn't tend to damage you too badly. Before punched cards there was paper tape, which I had to use to program a Varian 16-bit mini in the early 80s. After punching your tape you'd take the reel and feed it into the mechanical reader, which read at a couple of inches per second, steadying it with your hand as it slowly fed through. I go on vacation. Fast forward to two weeks later, when I'm about to feed my program into the machine, not noticing the spiffy new optical tape reader. I steady the tape with my hand, press start... and it reads at about 10 feet per second. There was yelling and blood everywhere. Quite some paper cut. Cards were very welcome after that.

Interesting note. Ever wondered where punch cards came from?

Believe it or not, they date back to the early 1800s and the https://en.wikipedia.org/wiki/Jacquard_machine for weaving cloth. They became used for computing in the late 1800s, notably for the 1890 census with https://www.census.gov/history/www/innovations/technology/th....

The inventor of that, https://en.wikipedia.org/wiki/Herman_Hollerith, founded one of four companies that became CTR, which was later named IBM.

When electronic stored computers became a thing, IBM naturally moved from mechanical computing with punch cards to using electronic computing with data and programs off of punch cards.

We like thinking of computing having started with electronic computers. It really didn't. Punch cards were the last relic of a history of mechanical computing that predated transistors, electronic computers, and even the vacuum tubes that electronic computers were first built from!

Punch cards for weaving looms date back to the industrial revolution (early 1700s) a century before Jacquard. That's like saying Watt invented the steam engine.

And the weaver workers revolted at automation of looms causing job losses. They threw their wooden shoes called "sabot" into the loom works in protest jamming it aka sabotage.

Citation needed.

Historians that I have encountered all say early 1800s for punch cards. For example the Smithsonian: https://www.si.edu/spotlight/punch-cards. Are you confusing those with earlier developments in textiles?

I also doubt your claim about when the industrial revolution started. Historians do differ on when the industrial revolution started. But you normally see figures in second half of the 1700s. For example they might cite James Watts' improvements to the steam engine in 1778.

For early 1700s you might be thinking of the steam engine, which was already in use. But the early steam engines were extremely inefficient. Their only real use case was for pumping water out of coal mines where both coal and water were available. The coal itself was being mined for use in fireplaces to keep people warm in the winter, because the forests had been cut down so there was no wood available.

The use of a continuous roll of paper with punched perforations to control a loom was invented in 1725 by Basile Bouchon. Then in 1745 Jacques de Vaucanson invented the first fully automated loom using punch cards which unfortunately was not well received at the time - perhaps due to pushback over the automation making the draw boy role redundant - and it wasn't until after his death that Jacquard reintroduced the idea alongside other improvements and was a success. de Vaucanson also invented the chain drive and slide lathe apparently, he was all about automation.

https://en.wikipedia.org/wiki/Jacques_de_Vaucanson

Funnily enough the Smithsonian doesn't mention his invention in their article on him:

https://www.smithsonianmag.com/smart-news/eighteenth-century...

There is a dark side to the story of punched cards too, as documented in this book.

https://en.wikipedia.org/wiki/IBM_and_the_Holocaust

When you know that history, IBM asking for an exemption to the JSLint license becomes less funny.

Watch https://www.youtube.com/watch?v=-hCimLnIsDA (2 minutes) to hear the story from the developer's point of view. Then consider how many totalitarian states today are using IBM computers to track their population.

The developer might not realize it, but IBM lawyers absolutely know that they can be fairly accused of using JSLint for evil.

> Then consider how many totalitarian states today are using IBM computers to track their population

Nah, the CIA, NSA only uses IBM mainframes to administrative tasks like payroll.

For all the tracking and spying their own population stuff they use linux like the rest of us.

Actually the CIA was known to be using NeXT. I believe it was the Intel port. (That said, any large agency probably uses a bit of everything, I know they use Linux now, managed by salt-stack I believe).

I wasn't referring to the CIA and NSA.

A lot of large organizations jumped on mainframes back in the 1960s and 1970s. That included US-friendly governments. Some of whom aren't very nice. Those systems and business relationships tend to survive. IBM is good about keeping it quiet. But occasionally someone notices and there is a scandal. The last major one was in 2019 when people found out that IBM was selling face recognition technology to United Arab Emirates. IBM discontinued that technology in 2020 because of the scandal.

There is a dark side to the wheel, if you use guilt by association. The problem was not one of technology, but one of immoral salesmen.

> They became used for computing in the late 1800s, notably for the 1890 census

Those census records would have been awesome. I was lamenting it's absence just yesterday.

I was an undergrad 1974-1977, taking computer science courses at McGill, before there was a CS major. Here was my workflow:

1. Write program longhand, on fanfold paper (more on this below).

2. Type program on cards. Those IBM 029 keypunches were the loudest, stiffest, most satisfying keyboards ever. The Model M is silent and squishy, by comparison.

3. Take cards over to reader. Deck is read, often without problems.

4. Go over to the lineprinter, and wait, with everyone else, for your output, printed on fanfold paper. This stuff flew out at a few feet per second.

5. Collect your output, debug.

6. Implement your fixes by deleting or replacing affected cards, and typing new ones, making sure everything goes in its right place.

7. Repeat from step 3.

Often the wait for your output was long and excruciating.

Fanfold paper was FANTASTIC scrap paper. I had so much of it, and used it for everything.

Every card reader/lineprinter station had an operator to deal with the inevitable jams and other problems. They would often get approached for programming help. One particularly cruel joke: "Oh, that's a color code error. You typed your program on the wrong color cards."

> Often the wait for your output was long and excruciating.

I solved that problem by getting a 10 hour per week job at a remote batch submittal station. It was in a quiet corner of campus, so I mostly had a card reader and line printer to myself :)

Oh... My favorite punch card trick that doesn't work well on "glass teletypes":

  debug = 0; /*/ ;1 = gubed
  */

I think I understand how your punch card trick worked for the most part, but how'd the last line work?

He would flip the card left to right. debug = 1

I under stand the flipping. But the last line (as written) wouldn't be read correctly, so the commenting out of `;0 = gubed` would never close.

I think another commenter figured it out, and the last line would need to be on a separate card.

The last line would be on a separate card, so it does not need to be reversible.

I wonder if you could write this on one card like

  /**/ debug = 1; /*/ ;0 = gubed /**/

That's what was tripping me up. I thought the last line was on the same card, so the close of the comment wouldn't be read correctly.

*/ marks the end of comment block

> Every card reader/lineprinter station had an operator to deal with the inevitable jams and other problems

on my campus in the late 90s there was an old lab with unix stations in it ( can't remember what they were) that nobody went to. I always ended up in that lab because it was quiet and the workstations worked just fine for me. They had these extremely high speed printers in there that were very large and under glass. I was playing around and did something.. i can't remember what maybe sent a binary to the printers or something... they took off and went crazy and caused lots of headaches.

I had the nickname "dammitchad" in some of the labs because "dammit chad, quit screwing stuff up" was a pretty common phrase. I was one of the "other problems" you mention haha.

About those printers...

Most people will tell you ISO 216 and DIN 476 are the same. this is not so

The DIN 476 standard has very slightly tighter tolerances than the ISO 216 and in the mid 90s I had the good fortune to meet one of those fancy new printers, under glass, yes, which no longer used continuous form paper but rather it used ISO 216 A4 pages. Or that's what you thought. It used DIN 476. Hundreds and hundreds per minute. The input and output trays were the height of an adult person.

And the moment someone bought A4 which was not DIN 476 compliant things went south. Very, very south. I believe the difference is half a millimetre (!). That printer was not mercifully designed.

I still have fond memories of working on the 029 keypunch machines, the keys made such a satisfying sound. I also remember the rooms where thousands of chads from punching the cards collected and had a certain smell and the bright overhead lighting, the ample air conditioning, the raised floors, the background noise of the machines, the whirling tape drives; it was an experience I'll never forget.

Fanfold paper was the best- we got a box of it (1500 pages or more) from the thrift store when the kids were little and they went nuts for years drawing super long trucks and trains and giraffes.

fanfold was my development platform. I would design and code everything on it, out on some hiking trail under a tree while everyone else was typing away in some office.

would have been more productive with an OCR feature.

In the mid-seventies at Swarthmore College, we were mired in punched card Fortran programming on a single IBM 1130. The horror, a machine less powerful than the first Apple II. My job six hours a week was to reboot after each crash. People waited hours for their turn to crash the machine. I let a line form once people had their printouts. I'd find the single pair of brackets in a ten line listing, and I'd explain how their index was out of bounds. They thought I was a genius. Late one Saturday night, I made a misguided visit to the computer center while high, smelled sweat and fear, and spun to leave. Too late, a woman's voice: "Dave! I told Professor Pryor he needed you!" We didn't know that Fred Pryor was the economics graduate student freed in the 1962 "Bridge of Spies" prisoner exchange. Later he’d learn that I was his beagle’s favorite human, and I’d dog-sit to find steaks for me I couldn’t afford, but for now I feared him. So busted! Then I heard this voice “See these square brackets? See where you initialize this index?” He was spectacularly grateful.

We had an ancient 1130 in our high school.

Not very much memory. I think I read and wrote to that giant pizza sized removable disk to do anything large.

Thinking back, I used punched cards for school projects. Wonder how they funded that, they were probably not free.

Neat. https://en.wikipedia.org/wiki/Frederic_Pryor

My dad, who wanted to move us to America for a long time, got his start in programming and the ability to achieve that goal thanks to punch cards. Hope it’s ok to share my anecdote thanks for bringing this memory up.

He has a basic certificate in metallurgy, and he had a job delivering punch cards from an IT company office to where they would be executed. He would wait, collect the printouts, and head back. I guess curiosity got to him and he got to know the guys there and started on his path of programming. It led to be able to move to America for a better life.

Long story short, my dad and punch cards as well as some super lucky karma are the reason I’m able to have a better life today :) thankful to this piece of tech.

Idle curiosity: what was the step between "he got to know the guys there" and "started on his path of programming"? How did he turn knowing some computer guys into becoming one?

"Back then", just being nearby and showing interest was often all that was needed. I remember wandering into the engineering computer lab my first day of college and being asked if I wanted an account by someone only a few years older than I. (I promptly locked up my shell, didn't know what to do and power cycled the machine under the desk. Got a quick reminder that multi-user machines didn't need to be the large rackmounted things I was used to. Oops.)

(My story about fathers and punchcards involves hanging out in the lab with my dad when he was doing his CS homework. I had great fun punching dirty words into the scrap cards and crashing while playing lunar lander on the greenbar printer.)

It was like this in the 90s as well. I would hover around noc closets and server rooms and just chat it up with the admin who came by. They were always eager to show off their systems. Then I would ask if they need help and I would end up doing network admin or sysadmin or building a system for them for a few months.

Come to think about it, this is still a solid activity at smaller shops. I have recently gotten work from my colo provider by simply chatting with them. The ROI is not the same as early days in my career but a sale is a sale

Is it really? That's great! I'd think they might be a bit more, um, reserved, nowadays.

He ended up getting a job as a cobol programmer at that IT company. The guy who ran the punch execution helped him understand what was going on and gave him some books.

The worst nightmare. Worse than any horror movie you have ever seen. The thing about punch cards is that they were a sequence! Think of any program you have ever written - the bigger the better - and put each line of typing on a separate card. These cards, no matter how many, are of absolutely no value unless they are in the correct sequence. Think about that.

When I was learning to program we had decks of cards. Each deck was wrapped in between 10 and 20 rubber bands because the very last thing you wanted was to spill the cards on the floor. One time I went into the little room where you submitted your job - a stack of rubber-banded punch cards - by placing it on the desk. Then you waited until it "ran" and they gave you back your stack.

Some guy came in and placed a deck, maybe 200 cards, on the desk, but WITHOUT any rubber bands. The five of us who were waiting for our jobs to run took one look at that stack without rubber bands. Each of us turned a deathly shade of pale and quietly left the room. None of us could stand even the thought of that stack of cards falling over.

That's why you took a marker and drew a diagonal line along the side of the stack, so you could visually line then back up if anything happened.

I mean, it wasn't great, but it was better than nothing

Exactly. Related: I wrote a blog post about the evolution of the developer experience a few years ago, including that tidbit: https://wanderingstan.com/2020-02-04/the-evolution-of-develo...

My tutor at uni told us about how he’d learnt to do that after tripping over the step into the batch processing room and having to spend a couple of hours carefully reorganising that evening’s program.

Altho of course as you modified your program, the cards got out of sync with the diagonal. I wonder if there was a technical term for this...

Exactly the same as what you do with a tray of photographic slides, in case you drop them

That is why programming languages used only the first 70 or so columns of each card. The last few columns were ignored and you could punch a sequence number. If you dropped your deck of cards you could take it to a sorting machine that could rearrange them in increasing order of the sequence numbers. The trick was to make your initial sequence number increase in steps of, say, 100. Then if you later had to insert cards in the middle of the deck you could use intermediate sequence numbers. This is also why the cards had one corner sliced off - you could immediately tell if a card was upside-down or flipped over.

I never used punch cards in earnest but your story reminds me of when I learned programming with BASIC and had to number each line -- it helped to begin with incrementing by 10 so that some lines could be inserted later without having to retype the entire program

... unless you programmed in BASIC, where the line numbers enforced the sequence even if the cards were out of order.

My first programming class used a machine that duplicated the physical layout of the IBM keypunch, but had a 1-line vacuum fluorescent display, and stored the "cards" on an 8 inch floppy. It was edit-able! You handed your floppy to the person in the little room, and got back your printout later on.

Not only did I program with cards (Assembler) in 1970, but my employer managed a master file of 40,000 cards, sorted by account number. Every day we posted updates by matching transaction files to the master, and selecting out cards that corresponded to updates. In the second pass of the day, we merged new and updated cards into the master file. Two hours per run.

1,000 cards/minute is an infernal racket. Imagine a picker knife slamming 17 cards/second by the edges. It would jam occasionally, and we had to meticulously reconstitute the torn card on the keypunch.

Back around 1979, I had one of the first home computers. So I was used to data-entry via the keyboard. (Even if that keyboard was part of an ASR 33 teletype.)

Off to the local high-school for a night-class on 'Computer Programming'. There we used punch cards for inputting our programs. However the card-reader was was one of the new-fangled optical ones. We only had to mark the punch-hole with a felt-tip pen by hand, instead of having the actual holes punched out by a card-punch machine.

That ASR 33 teletype above? Yes. I often made and read paper tapes with that.

Some of those early computers had no storage (it was a pricey add-on, at first) so even though you had a keyboard and monitor, you had to type your program by hand each time.

And it was still amazingly powerful compared to nothing at all.

storage (it was a pricey add-on, at first)

Yes. $400 bucks for 16 kilobytes. AND you had to solder all the components on to the board yourself.

Some time in the early 80's, one of my high school teachers had brought in a Heathkit (I think) microprocessor kit, where one programmed the 8 bit machine with 8 toggle switches, and a commit button. But my dad getting an Apple II+ predated that.

One trick of the trade I was taught early in my summer as a paid intern at IBM in London in 1974 was not to put my deck of 80 column cards on top of the line printer. The line printer was a large machine about 6ft long by 2ft wide and 4ft high so its top was a natural place to leave a deck of cards while you were waiting for something. The problem was when the lineprinter runs out of paper the metal cover hinges open by itself and tips anything on the top onto the floor.

Thank you for the anecdote. I'd heard horror stories of dropping a stack of cards and having to reorder them, so it's really cool to hear a story describing another way that can happen.

> I'd heard horror stories of dropping a stack of cards and having to reorder them

One solution was to run a felt-tip pen in a stripe across the tops of the cards in a stack, so that when dropped it was relatively easy to do a first-pass sort.

With beer!

In my youth I worked for a major UK Travel Agent with a global reach. As a junior operator I was tasked with feeding our card readers with decks of cards - usually a program followed by many hundreds of data cards carefully produced by Data Prep. So, one evening shift in Spring, we nipped over to our newly-opened "social" club, where we swiftly drank 3 pints or so of beer before dashing back to work. As soon as the mainframe room aircon hit me, I realised that the 10 boxes of punched cards of customers holiday bookings would be a challenge. I started the first box okay, then managed to drop the second and third boxes off the trolley. No problem, I just scooped up the cards off the floor and re-fed them - twice. Chaos ensued: the job abended, the shift manager went crazy and I was sentenced to spend the rest of shift decollating multipart carbon-interleaved paper. Never again!

When I started at GaTech in 1980 they still had card readers in the datacenter that nobody was using. I can't remember how we programmed (in Fortran 77) but it wasn't a whole lot more sophisticated than punchcards. Some sort of batch operation involving a trip to the service window. And a waiting period. I remember coding somehow on a paper teletype in the WREK studios. By the time I was finishing grad school 7 years later I was writing graphics code in $49 Turbo Pascal on my very own PC. With an add-on 80287 co-processor, natch. It was intoxicatingly awesome to sit down and code. Beautifully powerful. That's an astounding amount of progress. I don't think I've changed my coding tools significantly over the last 15 years. Emacs and c++ are better now, but the basic process & language are pretty much the same. I still have the 80287.

My first job in the valley I worked with a guy who had coded Cobol for the Air Force. He would write all his code and go over it for days executing it in his head not even a compile. He would then compile it. Fix the syntax errors - usually only a few and finally did some minimal debugging.

He did not have to work that way given that we had more modern tools. It was just his process from using punch cards.

I worked that way in my first job with a big consulting firm in the early 1990s. Better tools were available by then but a lot of client sites didn't have them. So you had a 3270 terminal and had to submit jobs for compiles. The queue could be several hours if the mainframe was busy, and fewer resources were available to developers than for running production. So time spent "desk checking" your code would often pay off in having to run fewer compiles.

Not a bad approach, as even nowadays the job is mostly done by the time your keyboard is turning designs into binaries.

As infrequently as possible! At uni. in the mid-70s I had a choice between batched Fortran on punched cards and interactive Dartmouth Basic on a Teletype with eight channel tape.

As a lowly undergraduate my Fortran deck had to be submitted to the operator as early as possible to have a decent chance of being run but I was never able to get the results until the day after.

After getting "Error in Job Control card 3" or something like that once too often I gave up Fortran and switched to Basic. I had to write more code but I could debug it much more easily and far more quickly with an edit-compile-run cycle measured in minutes instead of days.

My dad was a programmer, and had decks of FORTRAN programs, some up to two feet long. He taught me the trick of using a marker to make a diagonal slash mark across the top of the deck. If a card was out of place, it was obvious. If you were so unlucky as to drop all or part of the deck, it was possible to quickly put it back into rough order.

Later in life, one of my first jobs was a computer operator. By that time punch cards were mostly gone, but every once in a while someone would bring a deck in and I'd run it through the card reader.

Also, the CDC Cyber I operated could be booted off a small punch card deck. Essentially a bootloader in 3-4 cards.

I've worked with a few people who started their careers on punch cards. I learnt:

- Do not write a program if it does not need to be written

- Think about what you are doing before you do it

- Write with care and attention (whether code or prose)

Seems as applicable today as it was then.

Apologies for the off topic comment, but I don’t understand HN’s algorithm sometimes.

How is an almost day-old article with 126 votes still on the front page? E.g. above a post that’s only 11 hours old with 597 votes and 343 comments? [1]

I’ve been seeing this a lot lately, and it’s somewhat frustrating to see posts I’m not interested in drowning out others I find more interesting. I thought it might be the second chance pool [2], but that’s not the case here.

I’ve also seen articles that I think are very interesting and can generate interesting discussion with a lot of votes in a short span (e.g. less than an hour), suddenly drop to the second or third page, completely killing momentum. Maybe those are getting flagged, but they don’t feel like articles that should be flagged, and don’t ultimately get labeled as “[flagged]”.

Just curious in case others knew what might be happening.

[1] https://news.ycombinator.com/item?id=38172437

[2] https://news.ycombinator.com/pool

I call shenanigans on karma. This user, and that user has karma in the 10k range. It could be they have more priority over posted content on the front page.

Due to the secret karma protocol that goes on behind the scene, you'll don't know. HN features unlock at different point ranges as you may already know.

The ideology of internet points, upvotes / downvotes are broken; abused. In-that to downvote you should have to leave a reason to why your down-voting.

That would mitigate a lot of problems. If you don't want to give kudos, don't upvote. If you truly are unhappy with my comment tell me why rather than lurking in the shadows pleasuring yourself because you clicked a down arrow.

The system is rigged anyhow.

Some comments convey such a lack of goodwill that it would be a waste of anyone's time to explain to the author of that comment why it was worth downvoting. Usually, if a comment hits a critical mass of several violations of the spirit of the conduct desired here on HN, I'll downvote and move on.

If you think of what would happen as a group if someone say, posted a flame-bait comment, and then everyone who wanted to downvote it had to leave a comment _engaging_ with the flame bait: then you've given oxygen to that fire. It's most prudent to instead not engage and send a simple signal to the commenter "this comment was not well received". It avoids creating a dogpile of people scolding that commenter or spiraling into deeply nested argumentative threads devoid of curiosity.

Not my experience but a guy I worked with and respected. He retired and I haven’t heard from him, but from what he told me, one’s experience with punch card systems varied greatly due to the size of the shop. In larger shops:

The programmer would typically write out the program with pencil and paper. He/she would then pass that along to another programmer, possibly several, to have them review it and look for bugs.

The program would then be passed along to person who was skilled with a card punching machine and he/she would get the program entered.

Once the program was on cards, the program would be run. The print out of the result would then be inspected to ensure the program ran successfully. Often, the programmers would rewire the output board to cache the output and allow multiple prints. Once terminals became available, that cache could also be inspected with a monitor. Eventually on-line terminals became available and card punching went out of favor. Tape replaced it. Eventually tapes were replaced (for many but not all use cases) by floppies. Naturally, tapes still exist in some arenas for backup/archival.

> Eventually on-line terminals became available and card punching went out of favor.

In the late 70s our school's mainframe got a room full of terminals that let you enter & run "virtual punch cards". It sounds ludicrous but it was a godsend compared to dealing with physical cards.

The name of the terminal program was ROSCOE. Politically dodgy now, and back then too.

So much better than paper tape! My first adventure was on a PDP-8 that had a paper tape reader that was great but really slow even for that time. So a job with a real card reader that ran through a deck in seconds was cool.

(And I almost got to take a 360/30 front console until some company bought it for scrap. So many flashing lights and dials, I figured I could drive them with a Z80)

Our PDP-8/E in jr high school 4k core, with a later upgrade to a winchester disk (32Kb total storage) and a high speed tape reader. Still had to punch the tapes out on the KSR-33 but reading them was quite fast (relatively). If you were lucky, you'd get permission to use a bit of space on the winchester. Now that was a feeling of privilege.

> how did people deal with that?

Here it is, are you ready? They took all that time you waste on blogs, social networking, videos, games and web surfing, and used it to get their punched card shit done.

I also remember working with punch cards as a non-CS engineering major doing FORTRAN. Then in the middle of the course I discovered the timeshare terminals for another mainframe that had a link to the IBM 360 on which we submitted our jobs. All you had to do was create card images in the text files, including your computer money cards (worth their weight in gold) starting at column 7, etc., and then submit the job without having to wait in line at the card reader.

It was wonderful! No carrying around a card deck held together with multiple rubber bands. Of course Someone Official found out we were doing this, so for our last lab I had to punch cards out again.

Other tricks included submitting jobs to the 360 at the other campus, which took less money from your account, but was a little slower.

By thinking about things that were not applicable to the problem domain says Guy Steele in "How to Think about Parallel Programing: Not!": https://youtu.be/dPK6t7echuA?si=W6HvDKOLrNh9TQMl&t=254

It's a fantastic talk in its own right, but the first bit about fitting a program onto a punch card by self-modifying the code involved (and just how much thought was about fitting-the-program, and how little relatively is involved in the-purpose-of-the-program) is quite eye opening.

I like to think that I'm (M58) one of the youngest software engineers to have learned programming on punched cards. When I was in high school, and buddy and I took a numerical methods programming class (Fortran) at the local university. They had us do our first two assignments on punched cards. I believe my buddy still has his card deck.

Funny story. As a freshman in college, I took a Lisp class. Nothing but terminals in computer labs in 1983. The system was buggy the first week and the backspace didn't work. I remember thinking "this is as bad as punched cards".

(M60) here. first year of college, 1982. fortran programming. the basement of the physics building was called the "Student Input / Output Facility". A room full of keypunches, about 1/2 broken. two card readers and two line printers. there was a student employee on duty 24 hours a day with the job of keeping the printers in paper. The students had a line until 2 or 3am, waiting for the card reader.

There was also a room that said "graduate students only". It was full of ADM3 terminals, connected to the same CDC computer as the card readers / printers. Along with documentation. Lots of documentation. I never punched a card, but probably spent more time reading and learning how to use the time sharing system.

Hacker story. So, you want a student account and password? Make up a card deck with JCL that just copies from stdin to the printer. Put one 'blue card', which means "end of record". And no 'red card', which meant end of job. Get in line, run your job. The next student job (unless it started with a red card, which was recommended, but never done) would copy to the printer output of your job. First line was account name. Then a comma, and then the password.

You were in.....

That was the last year of cards. Undergraduates got terminals. And the CS dept got a pdp 11.

I work with a developer who’s a year older than you and says he was in the last class at his university to learn on punch cards, so you probably are among the youngest. At least for mainstream use; I’m sure younger computer history geeks still learn to use them for fun.

My understanding is that a year after taking the course that they scrapped all that equipment and reallocated the 3000 sq/ft of space for something else. So I just squeezed in.

My second co-op job was at a place that had mostly transitioned from punch cards but they still had a couple of hold outs. They wrote Fortran on special columned paper and then the keypunch operator would punch out the cards and the programmer would review the code. The keypunch operator would occasionally catch a typo and fix.

While I was there, the programmers started reviewing their code on the CRT and the keypunch operator was typing out the code instead.

By my second work term, one had retired along with the key punch operator and that was the end of that era.

First of all, those were the good old days.

I used to save GO TO and CONTINUE cards, including ones I found in the trash.

Then, I would adjust my control statements, which I had to type anyway, to agree with those cards.

I started out in the early 70s in high school, we used prepunched perforated cards, you programmed with a paper clip. We didn't have to pay to run programs, but the cards cost 1c a piece (a lot back then) - we'd recycle cards into new programs all the time

We were richer. We had two 029‘s in high school. In 1967.

And of the same vintage, hands up who remembers "line printers" (hence the device name lpr).

They had a row of solenoid driven hammers that would belt the paper+ribbon against a spinning drum or chain that was embossed with metal characters, typically 132 rows of 96 characters. The drums/chain spun very quickly. Big printers could print several thousand lines per minute (say a full page every 2 or 3 seconds, and much faster for empty pages.)

They were Rather Loud - all those hammers belting a spinning metal drum several thousand times each second.

A couple of tricks. Printers were not bolted to the floor. So imagine if all the hammers struck at the same time ... bang ... pause ... bang ... pause ... and the printer would increasingly wobble forwards and backwards, walking across its platform! The letters on the drum were staggered, so a row of "--------" wouldn't cause this, but rows of ABCDEFGH... would.

They used fan-fold paper, and blank lines/pages could be ejected VERY quickly. There was a built-in a limit on pages/minute but if you produced the right (wrong) output, and someone left the printer lid open, the stream of paper would flow straight out of the printer and start to bunch up in the air!

See: https://en.wikipedia.org/wiki/Line_printer

And a early one operating: https://youtu.be/FiEGoVzmyvs

That thing about 'you had to do more thinking up front, so you wrote better code' is total nonsense. Maybe the guy he interviewed; there rest of us were struggling with wasted runs because of syntax errors, cards out of order, worn cards that didn't read right...a total waste of human life.

Terminals meant you could iterate 10X to 100X faster. Which was the whole ball game right there. Because iterating wasn't (mostly) about thinking; it was about bookkeeping, typing. Expecially on a keyboard that operated a cardboard-punch-device that rattled and shook and jammed.

This article didn't say it produced better code. It said it forced him to think carefully about what he was doing before he input the code to the system, which made him a better programmer. This is very plausible. Lots of people, especially beginners, love to just spaghetti their way to a solution rather than taking 30 seconds to think about what they're trying to do and if this is the best way of doing it.

And make people better programmer it did :)

It's very usual now (and for the last 20-30 years) to see programmers live a loop of more-or-less randomly change code and see if it runs, repeat... Their code will eventually run, and pass the tests, but will be terrible - not understandable, inefficient, and break when confronted with reality or better tests.

When it was quicker and easier to think about the code, than play with it, people generally produced higher quality code.

I think the word you're looking for is 'agile'.

I have the feeling that we've had a constant increase in productivity, but the expectations keep being adjusted to take that into account.

We have more powerful tools now, but instead of having it easy we are constantly asked to do more in a shorter time.

I've often thought how frustrating it would be to go back to my first job as a product manager for large computer systems. I would find the inability to get anything approaching current information really annoying. Of course, everyone else would be in the same boat.

I'm sure some coursework and jobs would look a lot more similar than others. But we also take a lot for granted.

I didn't read the whole article but it is similar to what my mom told me. My mom worked for AT&T in the late 60's early 70s as one of the girls that would take your program and make the punch cards or take your punch cards and run them. She also said that you just checked it over as much as possible and got good at not making many mistakes because of how tedious it was. From what I recall, she said her dept. was basically a 24hour operation. She also said that she hated it and didnt stay in that dept for long.

That thing about 'you had to do more thinking up front, so you wrote better code' is total nonsense.

It's not total nonsense. However, people take it too far. The point is, does the candidate use their brain when using the tool, to use it to its full advantage?

There's a big difference between programmers who:

    - Just mindlessly step through the debugger
    - Do some groundwork so they know where to step
    - Has devious tricks, like writing a "tripwire" to activate a special 
      debugging version, and has the program find the bug.

So I find people who have this bias against debuggers just silly. It's not the tool that's the deciding factor. It's the programmer!

The same goes for writing new code and refactoring existing code. Does the programmer exercise their brain to utilize the tool to its fullest extent? The same even goes for prompt engineering and otherwise leveraging AI.

One shouldn't just stop at the surface level of analysis. Look for underlying principles. Try to get to first principles!

The best thing about punch cards and FORTRAN was punching a "C" in column 80; then the statement could be commented-out simply by reversing the card.

Except cards are keyed and unless you clipped the other corner, a reversed card would not fit in the card reader.

my grade school had a computer with a drum reader with fingers that would rotate. you would punch holes in each row to write your program. it had switches and lamps for input output for basic arithmetic functions. does anyone remember these or have a picture?

In high school we had the teletype and used rolls of punched tape to enter programs on a PDP-8.

At CMU they a IBM 360 batch processing we used for our fortran programming class. it used punched card readers. Our programs were always do Friday (Thursday Midnight). The batch process time from card reader input to compile and printout was close to an hour. My study group would write and enter our initial version, then hop in the car and go to Ally's bar for a piture of Iron City beer. We would come back, get our results (5 errors, 6 warnings) make the changes and re-enter, hop in the car for another pitcher. Came back and slowly got the number of errors and warnings lower. After 5 edits we came back and our errors were back to where we started. A case of diminishing returns I guess.

Maybe something like the Geniac[1] or a Paperclip Computer[2]?

[1]: https://en.wikipedia.org/wiki/Geniac

[2]: https://www.evilmadscientist.com/2013/paperclip/

Lots of awesome horror/history/difficulty stories in here. I never used punchcards but appreciate everyone's experiences.

My answer to the title is "because we had more time". Computer programs were doing such basic stuff that had such incredible value that we could take our time to build good domain models, in our heads and on paper.

Most (?I think?) programmers acknowledge (in theory) that the real work is not in writing the code, it's understanding the problem, making sure the solution solves it acceptably, and creating domain models and architectures. Yet all we see are the tools, and when we see a stone age chisel we forget that it's the thought that matters.

I attended Washington State University in the mid-70s. I had nothing to do with computers except my girlfriend was a Chemical Engineering major taking her one and only required programming class (CS being a subdivision of the Math dept. at the time). I spend long nights with her in the computer center, helping her punch cards and waiting for runs to complete. I had no idea what I was doing, but I collected enough punch cards with the WSU logo on them that I had bookmarks for close to 10 years after.

My only other experience with computers before that was a couple of years earlier, when my high school math class visited Boeing and did some sort of computer interaction over a teletype. Probably better than punch cards, but I didn't have my girlfriend with me...

I remember punch card Christmas wreaths. You twist each card into a cone (a kind of modernist holly leaf) and you staple them together in a big ring, spray paint green and add a big red bow. Somebody made giant wreaths this way for an office party.

Pinterest has a few examples:

https://www.pinterest.com/pin/58054282668538670/

https://www.pinterest.com/pin/here-is-our-holiday-wreath-mad...

I remember patching programs literally by applying a paper patch to a punched tape and then manually punching in a few assembler opcodes to effect a patch. Usually jump to an address at the end of the program where some new code was located in an unpunched section at the end of the tape followed by a jump back. Then you could test the patch and if good, punch out a fresh tape with the patched version. Was slightly more convenient than keying in the opcodes using the front panel switches although there were some simple cases where we did that too.

By bringing them home (my dad) and giving them to their kids for use as book marks, scrap notes, etc etc. I still sometime come across one hidden in an old book or (physical) file somewhere.

At school (1979) I used them in computer classes at school, where they were sent down the road to an insurance company that actually had a computer, and we got our compilation errors back the next week. My programs weren't long enough for serious card-deck disasters. But I completely agree with the TFA point that the very slow iteration makes you check things very carefully

In the Fall months of 1984 and the early months of 1985, I was in a tech school area of study that required us to punch the input source code for mainframe COBOL and Assembler programs. We also had a Prime mini in the lab with monochrome terminals. We used BASIC on the Prime as kind of an intro language, but they were pretty strict about learning about punched cards because some businesses in the area were still using them.

We would punch up a program along with a few Job Control cards and we'd place them in trays in the computer lab. About once every ten or fifteen minutes, a computer operator would stop into the lab. They'd gather the rubber-banded decks of cards. Then, they'd submit them for compile/execution. They would also deliver output printed on greenbar paper from the prior run. The instructors would grade on what should be a "clean" greenbar listing ( good compile and no runtime errors. ) They could still catch logic problems and such by reading the code, though.

When the card decks were left alone in the trays, some of the jokers I went to school with would punch up COBOL and/or Assembler comment cards with crude jokes on them and they'd insert them in peoples' decks to see if the instructors caught eye on them when grading the greenbar listing. Something like:

      * HEY, PROFESSOR SMITH.. YOU'RE CUTE!

When the system got busy ... like during finals ... you might only be able to get one compile/run in per day.

Using the keypunch machines was difficult. The print mechanisms didn't always work on the ones we had, so you couldn't always see what you were typing.

One of the students did have an unusually large program punched on cards and they dropped the deck in the hallway. They didn't have sequence numbers punched on the right edge so sorters couldn't be used. A group of us each took some pages of the last printed greenbar listing and a pile of the cards and we'd put together what we could ... trading the cards out to others like we were each solving little puzzles. I'm pretty sure that we got the program back together.

Not only did many of us have 8-bit micros at home where we could dash off programs in BASIC quickly, all of us were required to take BASIC on the Prime minicomputer ... so everyone knew that there was a better way. At the end of that first year, we got to use 3270-ish monochrome terminals which were much better. We could submit our jobs directly then, but we still had to wait for the greenbar delivery to find out the fate of our compile/run for batch jobs.

> One of the students did have an unusually large program punched on cards and they dropped the deck in the hallway

Maybe they hadn't learned that the first thing to do when you've just punched a large deck is to take a fat marker and draw a line diagonally across the top of all the cards. Helps hugely if you ever get them scrambled and need to sort.

My freshman year in college someone got the idea of having a weekend chad fight in the dorm instead of a water balloon fight, using chad collected from the little-known pull-out drawer at knee level on the 029 keypunch. The chad stuck to everyone's shoes and got tracked everywhere, with the sharp chad edges burying seemingly permanently into the dorm hall carpets. It was a huge mess, yet the dorm's weekday cleaning crew somehow got it all picked up in one day, and there were no repercussions.

I remember when I was a kid, my dad would get mail from the bank with punch cards. Checks? Invoices? Bank statements? No idea what they were, but I was fascinated by them.

I'm pretty sure he did a lot of work with punch cards himself, although pretty soon we had a printer terminal with keyboard calling his work mainframe over an acoustic modem. We played games on that thing and wasted tons of paper. No idea what the phone bill looked like.

Long ago a coworker told me about his summer job where the computers were at another site. Twice a day a courier would take your card deck to the remote site and pick up any output from your last run. If you were nice to the courier, you could get him to look at your output and possibly save you a half day by fixing simple errors and immediately resubmitting your deck. His co-workers weren't fast coders, but they rarely made mistakes.

I gotta ask. Did he accept tips for his helpful bugfixes ?

Funny, just today I had a reason to run a very old piece of software, designed around punch card input:

https://lss.fnal.gov/archive/nal/fermilab-nal-091.pdf

The input is now textual, but you still have to write “SENTINEL\nSENTINEL” at the end of the file so that it knows there are no more cards coming, for instance.

My dads collection of punch cards are a favorite childhood toy of my family. You fold some of them in half and those can be walls/corners, and the flat ones are roofs, and you make these giant multi-story play houses out of them and then perch your lego people everywhere, and then collapse them by shooting with rubber bands. Such a fun memory.

Now I look at them and amazed to see some are filled with my dad's FORTRAN programs. It's so fun.

I lugged around my favorite boxes of programs on cards for years, I even had big, full sized tapes, see [1], containing more programs I had written.

[1] http://www.columbia.edu/cu/computinghistory/tapes.html

Awesome!

A housemate of mine was in grad school when I was an undergrad in the 1980's. He was a child prodigy and had ended up in Comp Sci years before we met. He has memories as a TA, where his students would get frustrated with their program not running, so they'd shuffle their stacks of punch cards and reinsert them in the reader.

That was just a way of blowing off steam. By that time, the IBM card readers had an auto-sort feature.

> they'd shuffle their stacks of punch cards and reinsert them in the reader.

And yet...

https://en.wikipedia.org/wiki/Genetic_programming

About four days ago our professor was talking about how easy we have it and how he had to use punched cards to program. I didn't believe him (not knowing the history of punch cards, I thought they were much older than they actually were so in my mine he couldn't have been using them) but just yesterday he brought a pack of them with himself and showed them to us shattering all doubts.

I'm surprised that this guy had no choices other than paper tape and punched cards. In 1980! Around that time I saw machine rooms filled with line printers and magtape decks; sometimes there might be a card reader or paper-tape reader. But I never saw these devices outside of a machine room; they were for use by the operators.

Everone else used terminals ("glass teletypes").

There's a part of the 3h Dave Cutler interview where he talks about programming with punch cards: he became so frustrated at the jobs being rejected due to syntax errors that he wrote a program (run on a departmental computer with interactive access) to pre-check his card deck, allowing him to submit it clean to the mainframe. This was one of the first programs he wrote.

Here’s a story about disassembling a short binary card deck for an old time sharing system:

A CAL TSS debugging tool https://mcjones.org/dustydecks/archives/2023/04/22/1196/

I'm thinking of building a lego punch card reader for my 8 bit breadboard computer, and I like going down rabbit holes like this...

And I ended up here: https://www.masswerk.at/keypunch/ - virtual keypunch machine.

In the bad old days, you literally had to write your code by hand in an IDE and not just imagine what you wanted and have it written, deployed and executed for you. People used to go to school to learn how to write algorithms and then they actually got paid to do this all day. How did people deal with that?

- People, circa 2095

Just dont drop the cards

Run a marker in diagonal on the side of the deck. That way if you do drop them, manual sorting is easier.

See my other comment. At some point, the card readers gained an auto-sort feature!

A card sorter was a separate machine, as I recall. It had a few dozen bins that it used to sort the cards; when it was done you pulled the cards out of each bin in order and stacked them back into a single deck. If they were too out of order you might have to run the deck through the sorter more than once.

When I went to college in 1990 the university was still using punch cards for enrollment. You'd get a handful of cards representing yourself, then go around picking up cards that represented open spots in classes, and finally turn in the stack.

We had that in the late 70s. Tech college. It was kind of satisfying, because it was tangible, and you knew that if you had the card you had the place in the class.

My internships and first job out of college were all mainframe. Reading all this makes me very glad I had ISPF and USS. Reading all these stories make me wonder what war stories I'll be able to tell people in 40 or 50 years.

I remember as a kid, our phone bill was printed on a punch card, and the phrase "Do not fold or staple" was written on the leading edge.

By the time I was old enough to have my own phone bill to pay, punch cards were already forgotten history.

That brought back a memory!

IRS tax refund checks (not just bills) used to be in the form of a punch card.

https://images.app.goo.gl/rKuKR2FryEM8PRcb8

If you punched the right extra holes could you get a larger refund?

Or a lower phone bill. With tape and an exacto knife, it would be a worthy experiment (if it doesn't land you in jail, that is.)

The phrase "Do not fold, spindle, or mutilate" caused whole generations to wonder what a 'spindle" was.

Ah, "do not staple, bend or fold"....that brings back some memories: https://www.youtube.com/watch?v=5pTGf6Yw-1g

TIL https://en.wikipedia.org/wiki/Spindle_(stationery)

Very cool. I thought Spindle might be another word for 'Bend' since that is often used in that warning. But actual Spindling could change things considerably.

The very first computer programming course I took was IBM 360 Assembly Language programming on punch cards. We also did PL/1 and of course Fortran 77. I did a bit of COBOL, SNOBOL, GPSS and SPSS on cards, too.

We wrote MUCH smaller programs.

I started programming in college in the late 60's and it was cards up until the mid 70's when I got access to a PDP-10 with TECO as an editor. Online editing made longer and more ambitious programs much more feasible. Cards were sort of neat, though.

Related fun: the Google I/O 2021 punchcard puzzle

https://io.google/2021/punchcard?lng=en

I was intrigued by the book links in the top left. Has anyone read the author's book Problems With A Point: Exploring Math And Computer Science? Would you recommend it?

So the answer is exactly what one might expect: because no better interface existed, and these systems were what was available.

Don't get me wrong, I like the oral history approach to this question!

in 10 years time - people will complain about having to manually type out their prompts. and the 10 years after that - complain about why the computer didnt predict their prompts...

In the family memories of my great-grandfather, he describes how he used to manipulate the machine during night shifts (hospital warden) to sneak in a few hours of sleep.

Important issue was the bucket of "100 CONTINUE"-cards. Every freshman program always had this card, so could recycle them.

The nice thing about having assembler code on punch cards was that you could reuse them to “write” new programs!

We memorized most of our code and used line numbers to make sure order didn’t matter.

It wasn’t that bad.

It beat out paper tape by a mile.

Paper tape was big with the military because you could reload a computer after EMP. Maybe punch cards worked similarly ?

Slightly younger than the punch card era, but one bit of "old" tech I don't miss is the line printer. We had one in an office with a nylon carpet, and you'd approach that thing with utter dread because some combination of the action of the paper spewing out at speed, the metal guide bars for the ejected paper, and that bloody carpet meant that collecting a printout gave you an even chance of a massive static electricity shock.

rubber bands and clever wooden shelves, mostly.

This is completely irrelevant but I grew up in Stony Brook and have never seen the name anywhere outside of Stony Brook. Ever. Nor have I ever seen anyone be confused into thinking Stony Brook is one word.

The author potentially pays very little attention to their surroundings. It must make them a better programmer (/s)

On a serious note, I pretty strongly disagree that slower and longer feedback loops on potential logical errors leads to better critical thinking. It may lead to less rounds of errors, but that’s probably it.

Reply on news.ycombinator.com