"There is no quicker way to discover what n! means" Brilliant!

@siennamargeaux8413

8 жыл бұрын

+salmjak LOL His wry comment cracked me up.

Imagine a Windows update shipped as punch cards...

i cracked up so much at his n-factorial joke. that was brilliant

Professor B. neglected to mention the fact that back in the day, every program was written out longhand --- either on a form, or on a pad/in a notebook. We would "desk-check" what we wrote, and then we would sit down at the keypunch machine to enter our work line-by-line. It took a long time. There was a period in the 1960s when we had mark-sense cards for programming in Fortran, and I suppose other languages. You would use your special IBM Electrographic pencil (in retrospect, I'm surprised IBM product people didn't come up with one of their ridiculous names, such as the 9850 graphite depositing device!), and you'd have a specialized reader/punch produce your source deck. Writing code was a lot of work. You had to write your code, go somewhere to punch it (don't forget you had to punch your data too !!!) , bundle it up, take it to a job entry station or put it in a box for someone to run it for you (assuming compile, link and go), then return later to retrieve your printed output from "your" box. Depending on where you were, you might have to wait as long as 24 hours for your output...and the output might simply consist of compiler messages telling you that you'd missed a comma, or that it tried to compile 5 lines of comments because you'd forgotten to put a C in column 1 (Fortran). Your commands to the compiler might have been wrong....or your code didn't work the way you thought it should... or maybe it worked....and you'd end up with a stack of fan-folded greenbar paper to pore over. Debugging code was an art and a science. We'd spend hours and hours going over our code, using nothing more than paper, pencil and mind to trace the execution of our work. We took a lot of pride in our ability to write clean code and to debug quickly. Each of us would have our own stash of handy routines and test programs to assist in the debugging and testing processes. After we started using teletype text editors (some of the early ones were so bad, arcane and user-hostile, you'd wish for cards!), things became a little simpler. There were no "studios", or syntax checkers, etc. , but at least you could write your code, save it, compile it, and review the output without resorting to cards. Such memories! It's much easier now.

As a technologist apprentice we had opportunities to use these systems in the late 70's. However in the big company at the time all punch cards were made by a secretarial pool that was 100% female staffed. One of my colleagues who was a straight A type student, brilliant at everything, from a wealthy family, good looking and bizarrely also a nice chap who also was No 1 in all tasks kept failing at computing. He discovered why eventually. The girls in the card typing pool were 'adding' in messages on the job cards for him, asking him out on dates, and these didn't compile. Devil's own job to locate these little 'notes' in a stack of punch cards a foot high.

I learned to program on an IBM 1401 computer in 1971, It had 16 K of memory, and no disk drive of any kind. It could output your results onto a printer, onto a tape, or onto new cards. No consoles or terminals, just a big panel with some big buttons on it. Over the summer, the school system (yes, one computer for the entire school system of over 100,000 students) replaced the IBM with a Honeywell computer with 64 K of memory. We could not imagine what we would do with so much memory. Still no hard disks.

80 characters per card. So is this why still, in year 2013, for example Windows command prompt width is 80 characters by default?

I had the good fortune to be taught by Professor Brailsford in the late 1970s, and it is great to see his enthusiasm, knowledge and anecdotes still able to educate and motivate as it did me in his lectures all those years ago. Great to see the stack of punched cards - I still have my set from my first year Computing project - a Chess program written in Algol 68!

In the mid 1960's I punched FORTRAN cards for input to an IBM 360. Sometimes my stack of cards was several inches high. I'd draw on the top of the stack so I could watch them move down as the high speed card reader inhaled a three foot long rack of cards. What a THRILL when my job caused the reader to pause for a second before the line printer started. It meant my job had actually run!

if XP were on punch card(~40,000,000 lines), supposing a .007 inch card thickness and being able to fit all of a line on a single card, the resulting stack would be 4.42 miles tall and weigh 145.5 tons!

I first learned to code around the 2008-2009 time frame (when I was 24 (!)), and I love learning about all this really old stuff. I never took computer science in school, my only experience was a class I took on a whim that taught VB6, and I really missed out. Recently, I bought an old computer architecture textbook for a few dollars that takes you from all the way from how transistors work through the C language, and it's amazing.

Remember this video next time you are about to curse your crashing program..imagine the pain of debugging with set of cards!

Isn't it amazing that nowadays a supercomputer to them can fit inside our pocket! And we just use it to watch cat videos and get into random arguments.

I'm feeling a little old...I started as a IBM 370 mainframe operator in 1981. Computer cards and Hollerith code everywhere. Then we got a data entry system and the cards were gone (as far as programming and most data storage). Doing hex math in my head, pouring over dumps, then looking through card trays of data to find the bad punch that caused a data exception (usually from assuming character data was in packed format for calculations). Collators - patch panels, wow!

11:12 - that trick of drawing a big V, or writing a word across the edges of the cards is also used all the time by woodworkers when they figure out in which order they want to join a stack of boards, but want to work on each individually for a bit, say to plane or sand each before final assembly.

I remember having to read some cards due to an issue that occurred when I was in the military. Our unit was in support of 3D Infantry Division and their supporting units for JUMPS. This was the current pay system (1971). I showed one of the soldiers that worked with me how to use the three zones (0, 11, 12) to translate the punches. To verify what I was reading I had him to run the card through an interpolator which printed the characters on top of a duplicate card. I read the card that had no printing on top. The soldier verified what I wrote out to be exactly what was on the original card. I don't think I could do that today. I also had the opportunity to prepare cards for transmission on the IBM 026 AND 029. We called that "cutting" cards. Normally we would receive a box or decks of cards that had to have a start "Header" and end "EOF" card made. The start card had the routing, serial number, classification, card count. The end card had the same thing to verify the card count. The card count always included the body or deck number and the two additional routing cards. The end or EOF closed the transmission of the deck with four Ns (NNNN). If the Header and EOF card did not match in the card count when the transmission ended, I would have to answer a service message that was generated from the system and recheck the deck by running it through an off-line card counter. I can't remember loosening any cards or sending any decks to the wrong station during my tour. I can say that I really loved doing that job. Thanks for a trip down memory lane with this video.

The David Attenborough of computer science.

We worked on a massive Finite Element Analysis program in the late 70s. The master copy was stored in cabinets of trays of punched cards that covered one wall of an office. The usual practice was to use a ruler and magic marker to draw a diagonal line across the edge of each deck. That way, if you dropped a tray, you had at least a fighting chance of getting them back in rough order before having to go through each card to get them into the proper order.

Everything I just heard I knew already. From my first computer-operator job. And I am relieved to learn that I did not exaggerate one bit all these years.

I used the beveled edge to mark cards that needed attention. I would sit at my desk and proof read a program deck. When I found an error I would turn that card around so that it's square edge would stick out of the deck's beveled edge. Therefore keeping my place and additionally marking the deck as not ready for production.

I used punch cards and we had little silver stickers to cover up holes when we made a mistake. Also special characters used 3 holes per column. The electric punch card machines were in great demand so programmers were often forced to use manual ones with a key for each possible hole in a column.

If you use two different colors and draw an X then it gets really easy to sort them faster because you can easily identify which cards belong in the first half, and which are in the 2nd half. When you have a thousand or more cards little things like this trick make a big difference.

The old IBM systems (pre-360) was a computer with a whole series of peripherals: a collator, a sorter, card reader and punch, and a printer. Many functions could be performed directly on the peripherals with only minimal control by the computer. The machine that sorted your cards into order was the sorter; the collator did computations on the column data based on "programming" a hard-wired panel. The keypunches moved the cards mechanically. Some card readers used compressed air to pull cards off the deck quickly; the slot they had to go through was precision set to allow only one card through, and the compressed air kept a warped card from stopping the process.

for me as a developer thats like listening to a bedtime story ;) love it! It was really complicated back then, I am glad we have editors and real files nowadays.

My father worked in bank data processing until 1980, and they used these. My mother was a keypunch operator.

In some shops, programmers would not even punch cards themselves. The programmer would write his program on a "coding form", which came in a notpad, each form sheet having 24 lines of 80 columns gridded out, plus some heading fields for identifying the programmer, department, etc. The programmer wrote his code in blocked letters, one letter per column, one line of code per row on to the form, according to the format of his chosen language. After appropriate desk-checking to make sure the code was seemingly correct, the coding forms would be submitted to a punched-card operator (a typist skilled in the use of the punch card machine). After the program was punched up, the programmer could swing by later and pick up his deck of cards, with the original coding forms for corrections if needed. Once the programmer was satisfied, he would submit his deck to the computer operator with some additional job control cards (as shown in the video). The computer operator would run job decks in order of submission, returning decks and associate line printer output back to the programmer. Whew! The turnaround on logic errors was brutal, often 24 hours or more to make any correction, which is why visual inspection of the original coding form was so important.

This is great. I am old enough to actually have worked with those cards and related systems. Long before machines could read human writing (scribbles, sometimes) I used to be employed as an alphanumerical datatypist. The machines hummed, all kinds of levers and mechanical things in working. Splendid. Thank you for this movie!

It was a good idea to always use sequence numbers in your cards. For IBM 360 Assembler the sequence number was in columns 73 to 80. You could tell the assembler program to verify that the source deck was in sequence. Column 72 was used to continue the card onto the next card - this was commonly used for 'macros' such as the DTF or DCB declarations. At the place where I learned programming, via OJT (On the Job Training), we had several IBM card sorting machines which were invaluable in the event of having dropped a deck of cards. All serious programmers should know an Assembly language. That way you have a much better understanding of what is actually being done by the hardware. Even in 'C' it is possible to write your code to take advantage of the quirks of both the compiler and the hardware. Of course it IS possible that what is best for one system is not the best for another.

It's amazing how UNIX is referred as the "next step" in the whole explanation. Thanks for sharing how punch card worked. I liked the method of drawing pen lines on the side in case they ever fell off. Those were the real hardcore days to be into IT.

Back in the 70s, I used to maintain punch card equipment. As I recall, the official name for the device was "Interpreting Data Recorder". Also, way back in my grade 12 FORTRAN class, we used pencil mark cards. These were the same size and shape as a punch card and could even be read on some card readers. The 12 hole column was split into 2 6 mark columns, staggered so that the mark in one column was next to an unused area in the other. Incidentally, punch cards are why so many terminals and printers have 80 columns.

I used to play with these as a child circa 1983 in Russia :) They were very much used in the State Statistics Office where my mother worked.

I started programming in BASIC back in the mid 1970's and later wrote some programs in FORTRAN using punch cards. I could type faster on one of the IBM keypunch machines I had access to than I could on an actual typewriter of the day. It was something about the height of the chair, the height of the keyboard on the punch card machine, and the amount of force needed on the keys of the keyboard. I still remember the basic idea on how to read a punch card from the holes in it. I was able to read a few characters off the cards shown before the text was shown at the top of the card. I may still have something that has the details about the characters for each pair of holes in a punch card. I have a couple of programs in a box that are on punch cards, I have a manual for an old IBM keypunch machine in a box somewhere, and I even have the control drum for one of the old IBM keypunch machines. Ah, what memories it brings back thinking of these things.

I worked for the CEGB in the 1960's and spent many a happy hour loading trolley loads of cards into the reader connected to an IBM1401. We transferred all the jobs for the day onto magtape, to be run overnight on an IBM 7094 running the IBSYS operating system. The IBM7094 had 12 tape units and a giant DRUM. When a batch finished the tape units would go into high speed rewind mode - what a site - just wished I had taken a video of it. It is a shame the video does not show a hand-punch, because if you were desperate for a job, which had failed and you knew which card was wrong, you could hand-punch a new card. I still have a few cards in my desk drawer -for nostalgia's sake. If I remember correctly ICL could also read smaller cards - about half the width and less tall. I'd love to hear some horror stories about punch paper tape problems. Later we had an IBM punch-paper tape device that continually clogged up - IBM was cards - not paper tape. Later as an assembler language programmer on Honeywell 200 series - when a job failed - and you worked out what the problem was - you went to a hand-punch and created a patch deck that was added to the end of the program - all done in octel. Happy days and thanks for the memories

There was a begin and end card, a run program card and 1 card with 54 numbers whose position and value specified the location of each of 6 colors on the cube. The line printer would then print out a sequence of turns that needed to be made to your unsolved cube in order to solve it. I received an A+ on that project.

I used punch cards until I graduated from college in 1979. When I was a child, they were everywhere. Now no one remembers what they are/were.

There are some pictures of the kinds of machines Professor Brailsford is talking about in the original Mainframes film - see the description for a link >Sean

While using it a lot, it is easy to take the humble "return" for granted, when getting information from one place to another. To have the output physically handed to you on a deck of cards and then having to manually having to insert them to deliver the output to where it's needed, now that is something I am glad we left in the past. Sorry "return", I'll never take you or your automatic delivery for granted again. We young people have it so easy today because of you.

My father used to work with these things many years ago: when I was growing up, there were great stacks of old punch cards in the house that he had brought home (presumably discarded from use), and he would explain to me (approximately) how they used to work. They were already obsolete when I was a child, and I am 36 now!

Christ. Programmers these days have it easy.

I used to draw a diagonal line with a felt marker...

The school I went to in the mid 80's for programming had a punch card writer and reader we had to learn it to pass the course. Our professor advised us to run away from any job offers that came our way in they needed to use this equipment.

Thanks, I love this guy. I recall using punch cards in the 1970s when I was in public school as well.

this takes me back - thanks! - old ibm mainframer here - one could multi punch any of the 256 byte combinations using an 026 keypunch - these values might employ more than 2 holes - also if you dropped a deck, in addition to the methods you mentioned, you could compare to any listing you might/should possess - a dropped deck is rarely completely random - blocks of cards tend to clump together - i think our last card conversion was 1980ish - thanks again!

As a Business Major in HS I took Keypunch and Collator Classes. When I got into the Marines I ended up applying everything I learned in HS. Interesting work.

this is so cool that there are ppl that can tell u and explain the history of machines we are using today:) i love this channel and hope to see more guests with such great knowledge

Memories. Mistype or omit a character and there was no undo, backspace, or delete key. You had to type the whole card again. Computer took up two floors of the engineering building. Cards came in two foot long boxes. Used a slide rule, and log and trig tables and considered myself lucky to get three decimal place accuracy. I wouldn't go back. Give me my calculator, smart phone, and laptop any day. Thanks for the video.

When I was a kid they used to give these cards to the public school. I still remember how much fun it was to build cars, houses out of these cards. Very pre-minecraft

just 50 years ago ... we have come a long way

(continued) Once storage got larger, the operating system stayed in the machine between jobs, but you would still have to load the compiler. Early compilers were "multi-pass," where the computer punched a deck of "intermediate code" because the whole compiler was too big to fit in the computer, so it was split up into "passes."

My first job in computing began in 1971, working on an IBM 360/44. One of our card punch machines did not print on the cards at the top. I became adept at reading the holes.

I remember going out with a girl who was a programmer. Most people were using Monitors to input into for computers by then but some of her programming was still done by punch card so always had rubber bands on her wrists. My Dad while he was programming always had punchcards at home, think he was checking them, I was very young. He ended up running the department,Employment as programming was nwever decided on your Academic qualifications(although he had degrree). If you got an A or better on the IBM aptitude test you were if you interviewed well you were employed.Most had A+ scores.

Heard about punch cards for a long time but never cared to find out about them. Today I saw them for the first time. I can imagine how much some old people miss that era, the same way I miss my floppy days. I guess their days were more exciting.

My first FORTRAN course at university used punch cards and the typewriter ribbon was hardly ever changed so you couldn't read the line on the card. We learned to draw diagonal lines on the card stack very early on and we'd write numbers on the card as the reader would jam all to often. This was the early eighties and as undergraduates we could only use the old out of date computers.

Wow, I can't imagine the hairpulling errors that must happen when those cards get mechanically punched incorrectly. It's easy to forget when I write code these days that I don't need to worry about my code not getting mechanically read.

@kyoung21b

9 жыл бұрын

Spuds7er - Yes, I'm amazed that I have any hair left at all; both for the reason you state, and also given that I've been around long enough to have been exposed to that hazard !

I always enjoy your videos on the history of computer technology and programming. My professors would mention the days of punch cards and I always wonder how they worked on a high level. Thanks so much for making this video!

My father worked for Defense Computational Resources Working Group, and dealt with writing programs on punchcards. He had developed an optical auto punch card system and had special cards printed up for it. Those cards would have little boxes over the punch area. So you'd must mark it just like those old scantron tests. Then you'd feed it into the keypunch machine and it would automatically detect the mark areas and punch them. This was in contrast to doing it manually on a keyboard like he said. Ok. Then he had a system of transparencies with commonly used snippets of code written out, and an overlay pattern to trace at the bottom of it. He'd put that on a glass table and put the punch card on top of it so he could mark down the spots that were blacked out underneath. So it was a primitive way of using programming libraries, heh. He said he got the idea from a story he heard about Bletchley park where they would use transparencies to help identify numerical patterns in codebreaking. Later on when xerography (that's photocopying) came out, he'd just put the transparencies into the photocopier and then trim down what it spit out and fed them into the optical-punch machine. There were some other cool innovations, such as optical tape for feeding the patterned program data that way. That was just a flim negative with the optical "punch" patterns exposed on it. That of course needed a highly modified reader, but he said the system worked well. The system used for "recording" the data onto the microfilm was real low frills he said, and consisted of a Minox camera. He said he managed to get about 2k info of information onto an exposure of 8x11mm film, a roll of which held 50 exposures (and was dirt cheap).

"There is no quicker way to discover what n! means" haha love it!

Wow, best explanation of punched cards computing i've seen anywhere.

In 1973 I dropped a whole box of punch cards containing the complete accounting "database" for the organization I worked for. For a few moments there was complete silence in the room till people, including myself, recovered from the shock. Luckily for me, 2 things were in my favour... 1. There were still large blocks of cards still in order on the floor reducing the effort required to place them in sequence. 2. All the cards had sequence numbers in the last few columns so I could verify they were in the correct order. Unfortunately we did not own a card sorter so I had to spend the next few hours putting the deck back into the correct order. The deck was then read into the mainframe's card-reader and the contents printed out so I could visually verify the cards were in sequence. Luckily the cost of the computer time was not taken out of my pay. I never dropped a card deck again after that.

That was my first job in 1966

Kids these days don't know how good they have it. I just barely missed the card punch era, but my professors were always on me not to let the compiler find the bugs in the program, because when they went through school they were charged for their jobs whether they actually compiled or not. I do remember having to type the bootstrap sequence into an ancient DEC machine (PDP 11/03 I think) at RPI for an assembly language class, in order to boot our 8" floppy. Ah, the good ol' days...

Until the late 70's every bill had a punched card in it with the iconic words "Do not bend, fold, spindle or mutilate" on it. If you were late on your bills you could swap two different cards and claim you made a mistake. You still had to pay the overdue bill next month, but if you were lucky you didn't have to pay a penalty. My mother did data entry on a punch machine 8 hours a day for about 7 years. She said it was the most relaxing job she ever had.

Back in college I asked my professor if I could combine the class projects into 1 larger project. I wrote a Fortran program to solve Rubik's Cube. It was appx. 1500 punch cards and would take so long to load and run the computer lab was tied up for nearly an hour just on my program. This was such a problem I was given permission to store my program subroutines as they were debugged onto magnetic tape so I wouldn't have to load the cards each time. When finished, t only took 4 cards to run.

Okay. When we ran punch cards using Fortran, we were taught to number our cards, either by writing on them or by adding a printed comment in the code. If you had to add an extra card in the middle, you'd just use a decimal point. Simple, but easy enough to straighten out "n!" accidents. circa 1978.

We look at it today and wonder how we ever got by with such primitive stuff... And yet NASA managed to land men on the moon with this very same computer technology. :-)

Thanks for posting this! It's really cool to see where the modern program languages got their semantics!

Soooooo many people needs to hear that.

Priceless video! Thank you so much for sharing!

Are the stacks of cards where the term "stackload" comes from?

Some columns did have more than 2 holes per column, number used a single hole, letters and three special character used 2 holes. All the other special characters had 3 holes. There were also binary decks that could have any number of holes punched per column depending on the instructions or data. On our old Honeywell mainframe we had a complete binary program stored on a single card that played a simple gambling game. It had many holes per column. You can see 3 holes in column 1 in this video at 8:17

I'm watching this on a smartphone. The progress is constantly blowing my mind.

Woah, such a blast from the past. Great history lesson - and to think that it all happened barely 40 years ago!

Thanks for this, a fascinating insight into how things used to be.

When I started at my second workplace in 1990 they'd only recently migrated from an ICL 2900 series mainframe to a S39L65 dual node. We had a little ante-room called data prep where there were card punch and card reader workstations, but they had just moved away to rudimentary VDU input directly into wired terminals. So, I never quite managed to witness the world of punched cards in production UK public sector life, but I feel that I was fairly near the start of the VDU era and use of VME rather than TME. There was still a lot of mainframe mentality as much as technology; we would carve up the day into Transaction Processing (TP) and Batch times, with pretty hard immutable rules for what was and wasn't allowed in each window.

Actually had not just the card drop experience way back then... but turned a corner too quickly with my stack and ran head-on into another student with his card stack. Oh what joy that created :-)

@09:27 The corner cut could be in any of the four corners, and intermixed in any order, as long as the card's orientation when read was the same as when it was punched. If the card was punched backwards and upside down, then it would have to be read backwards and upside down to be interpreted correctly, but the equipment could not detect either the corner cut nor the printing.

Thanks great video, learnt a lot. wish I had been there in the early days, thankfully I got in at the 8bit stage. But to get in to computers today must be a lot harder to get your head around than in them early days. I remember building my first logic state computer and it taught me so much on how to grasp the workings of what a computer is/does etc.

I had stacks of these as a kid, used them to make all kinds of things. My dad was a COBOL and Databus programmer starting in the mid 60's.

Card sorters :-) ... & binary puchings Back in my starving student days, I'd dive into the card recycling bins, pull out bunches of cards, and run them repeatedly through the card sorter - one could only sort by a single column at a time. By repeatedly sorting, I could sort down until I sorted out down to all the cards that had the first - or last - 40 columns all blank. I'd then save those cards and return the rest to the recycling bins. I'd then use, as one of the first control cards in my program, a card which effectively said to only read the first 40 columns, and ignore the rest. Thus I managed to avoid the cost of ever needing to buy blank punched cards - which were sold for $0.25 USD per 100. A small percentage of those cards found were also completely unpunched - that was enough to cover the few lead (and possibly also end) cards I needed before the control card that limited the significant reading to the first 40 columns. And all these >= 40 blank column cards, I not only used for the punch card programming, but those >= half unpunched cards I also used effectively as "index" cards for the paper writings and the like, where I first needed to do outlines, and often sort and rearrange various bits before working into a draft and final paper. Binary punchings - though not so commonly done, the cards could be punched in a true binary form - typically done by computer card punch, not a keypunch station. That would give significantly greater data density on the cards - but also a structurally much weaker card, as on average half of all the holes would be punched. I even made some cards with all the holes punched - quite flimsy - and yes, they could be read, but unlikely they could be handled much and repeatedly read very successfully before suffering mechanical damage and jamming or tearing.

"No best way to learn what N! is" love it.

Cool video! I remember my mom telling me about the old FORTRAN 77 days of punching cards. I tell her that the 2008 standard isn't much better. There's still a default fixed-form limit of 72 characters per line, and we still refer to things as "cards" and "decks" despite everything being stored in electronic form.

I remember my first CS class in 1975. We punched our little program onto cards and the "Perfessur" gave us each a few cards to put in front of each one. These were IBM JCL cards to run the jobs at the computer center. Fun times.

I know the 029 punches I used to use didn't print anything, it just punched holes. You had to number them by hand to protect against mixing them up. There was one 029 that did print what was on the card but you had to have an act of congress to be able to use it.

Two major funnies stick out in my mind regarding punch cards, one at the beginning of my career in the late 1970s, one towards the tail end in the 2010s: > Early Career: Straight out of college, I was working at a company developing a new payment tracking system on a Data General "mini-computer". My predecessor was an old mainframe guy, and, as the professor notes, would carefully update his program deck (COBOL), then read in the cards (close to 2,000 cards, if memory serves), compile the program, get his error report, then update the deck and start the process of re-loading the card deck into the computer and compiling again. Very time consuming! I was the hot-shot new kid, who was not only used to mini-computers, but also was quite versant in online text editing. The day after my predecessor left for a new job within the company, I loaded his card deck into the system one last time. I then, in full view of my manager, proceeded to take the box of cards and dump them into the trash bin. Needless to say, I got a horrified look from my manager, but I assured her that any and all corrections could now be done directly using the text editor. Much faster, and a lot less error prone. Of course, I hit my deadlines, so she couldn't complain. Of course, that was not the last of my hot-shot stunts that I pulled on the project. Luckily for me, all of my stunts paid off, and we went live on time. > Late Career: I was working at a large bank that had brought on a lot of young programmer from India to work on the development and support of our systems. One day, I casually mentioned my use of punch cards back when I was their age. To prove the point, I brought to work the next day some sample cards I had lying around my house (they make great bookmarks, by the way). Seeing their amazement and confusion over the cards was a lot of fun. I was only too happy to give them a few lessons in computer programming history, something that they never got in school!

Fantastic video! I loved the detail.

3 am., baby in arms 30 inch pile of punch cards and the typing skills of a chimp...writing code was one thing...getting it all down on the cards--another!

@Improbabilities

9 жыл бұрын

As someone who has been studying programming just in the last few years, and getting annoyed about having to write the exams on paper, this really shows how spoiled I am.

In early 90's I was playing with such cards - original from 70's. I used them to color numbers and generally draw on them. I don't have any card left. If I'd know their value back then... Well, even if they are now valuable, I'd love to have it on the wall and of course give most of them to local IT museum. It hurts they ended up in the trash bin.

I did computer studies ‘O’ level in 1982 in the tech’ night class and the (hands strictly off) mini computer read punched cards. I searched the house recently and didn’t have a single card left. Used cards didn’t really have any secondary re-use, the holes ruined writing on them. The tech’s ‘mini’ computer was fairly ancient back then and took the best part of an hour to manually reset after a crash. It was the size of a cupboard.

There were "keypunches" with typewriter keyboards (there were typewriters, too), and there were "cardpunches" that were automated and punched cards at amazing rates. Still, at 80 characters a card, an "amazing rate" was still low bandwidth. Tapes were the way to go for speed. "Never underestimate the bandwidth of a station wagon full of tapes driving down the interstate."

You stated 80 column and the video stated 80 column cards. Professor Brailsford discussed a 6 bit computer in the video and stated it was done to make it cheaper to make. So,you're correcting me on things not discussed in the video. The 6 bit 80 column cards are 480 bits. The ones I used were 8 bit, but that wasn't what was being discussed.

I remember the Keypunch machines back in the 70's and 80's!

This video makes me feel old.

My dad used to bring these cards home for us to play with. He also used to bring home the peaces of punched out card.

Awesome man, thanks for posting this.

I used punch cards in college - we were the last year to do so in that school - it was 1982 at Norwalk State Technical College in Norwalk, Connecticut. I don't miss them, but I'm sure I still have boxes of them in my mother's attic.

I was an IBM CE starting in the mid sixties. Repairing 024, 026, 029, 056, 059, 080, 082, 083, 084, 557, 088, 1401, 1402, 1403, 360 and related peripheals(tape drives, disc drives, 1403n1, selectric I/o etc.) Was trained by IBM while in the MARINE CORPS and served two tours in vietnam repairing the aformentioned equiptment. Continued in this occupation for many years as a civilian.

Nice explanations and comparisons!

the 8086 was a 6 bit processor, ibm/intel jumped to 8088 the next year with an 8 bit processor. all of our modern pc processors are still based on that old 6 bit processor, aka x86. with 286 you got a math co-processor option, with 386 you got a math co-processor requirement (with a cache option), with 486 you got math-coprocessor integration (with a continued cache option). i am just trying to say that 6bit made it's way into the 80s. (and yes, the 8088 did have a math co-processor option too)

Damn kids, when I was your age, we had pendrives made out of paper.

Nice work , Sean!