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.
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.
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.
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'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.
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!
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.
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 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.
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.
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.
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.
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.
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.
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":
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.
> 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.
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.
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.
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?
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.
"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
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.
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!
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.
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).
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.
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.
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.
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].
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?
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.
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!
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!
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.
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.
> 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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
187 comments
[ 2.6 ms ] story [ 217 ms ] threadBy the time I was old enough to have my own phone bill to pay, punch cards were already forgotten history.
IRS tax refund checks (not just bills) used to be in the form of a punch card.
https://images.app.goo.gl/rKuKR2FryEM8PRcb8
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.
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.
We have more powerful tools now, but instead of having it easy we are constantly asked to do more in a shorter time.
I'm sure some coursework and jobs would look a lot more similar than others. But we also take a lot for granted.
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:
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!
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.
And it was still amazingly powerful compared to nothing at all.
Yes. $400 bucks for 16 kilobytes. AND you had to solder all the components on to the board yourself.
That was just a way of blowing off steam. By that time, the IBM card readers had an auto-sort feature.
And yet...
https://en.wikipedia.org/wiki/Genetic_programming
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.
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.
He did not have to work that way given that we had more modern tools. It was just his process from using punch cards.
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."
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":
I think another commenter figured it out, and the last line would need to be on a separate card.
I wonder if you could write this on one card like
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.
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.
would have been more productive with an OCR feature.
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.
(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.)
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
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!
https://en.wikipedia.org/wiki/IBM_and_the_Holocaust
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.
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.
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.
Those census records would have been awesome. I was lamenting it's absence just yesterday.
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.
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...
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.jp...
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.
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.
\\GO.SYSIN DD *
DOO DAH
DOO DAH
(Checks beard color and blushes.)
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!
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.
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.
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.
Now I look at them and amazed to see some are filled with my dad's FORTRAN programs. It's so fun.
[1] http://www.columbia.edu/cu/computinghistory/tapes.html
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!
https://www.pinterest.com/pin/58054282668538670/
https://www.pinterest.com/pin/here-is-our-holiday-wreath-mad...
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.
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.
- People, circa 2095
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.
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:
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.
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.
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.
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.
[1]: https://en.wikipedia.org/wiki/Geniac
[2]: https://www.evilmadscientist.com/2013/paperclip/