I started programming in 1970, on the IBM 1440 computer. The program source went to the keypuch department, which used the IBM punch card machines to enter the source onto the standard card decks. These cards were then fed into the computer's card reader as input for the language compiler program. (Assembler, RPG, Cobol Fortran or P/L1). The compiler converted the source into machine code, then sent the machine code to the computer's card punch. We had special plastic coated punch cards for the compiler output, because these cards got read so often. To run a program, such as order entry, we would get customer order header and detail cards from the keypunch department. You would take them to the card sorter, and sort them by fields like customer number and order number. These data cards would be placed behind the program cards for the order entry program, and then put into the computer's card reader. The loader cards at the beginning would tell the computer to read the program cards and load them into the computer's memory. At the end was a card that told the computer to start executing the program, and the data cards would be read and processed by the program logic.
I also wrote programs in university on coding sheets that then got converted to punch cards. Prior to that we wrote programs to paper tape.. what fun..
@@MrWibbleman I did paper tape too. Then the punchcards. After the paper tape, those punchcards felt like a giant leap forward. And then, the great miracle of typing APL on that IBM keyboard...
@@davidcassell4659 Ditto! Loved APL. Still can't believe though that we only had a workspace of 22k! 44K if you usd the backup space as a workspace. Never used the punch tape though... although the teacher showed us some. We went from Fortran with the large punch cards, to the small punch cards, to Basic then to APL on the terminal. If I wasn't in the darkroom, I was in the computer room. I can still recall dialing up the main computer on the phone, waiting for the modem tones, and plugging the phone into the coupler. Ah... the good ole days at 300 baud. 😂
I started university in 1977. Of course, no student was ever allowed to use one of the few terminals to access the IBM 360. We were taught FORTRAN, later ALGOL and SIMULA. After hours of punching cards we had to hand our box to one of the operaters who then loaded the cards into the card reader. That thing was fast, at least we had the impression. After some hours of waiting, we got back our box together with a printout on fanfold paper, only to find out that we had made silly typing mistakes and the job hadn't run because id didn't compile. Argh!
This eighteen-minute video takes 144,667,920 bytes of storage as an MP4 file. If we were to store that file on punch cards using only eight rows (one for each bit), it will take 1,808,349 punch cards. Since each card is 0.007 inches thick, the stack of cards will be 12,658.44 inches high, 1,054.87 feet tall, or 905 boxes of cards at 2,000 cards per box. A card reader reading at 600 cards per minute, will take 3,013.92 minutes or 50.23 hours to read 1,310,793 punch cards. 16,500 punch cards weigh 99 pounds, so this stack of 1,808,349 cards will be 10,850.09 pounds.
"using only eight rows (one for each bit)" Which isn't actually realistic. This would require *lots* of holes to be punched in some cases. This was avoided, because doing so made the card structurally weak, making it more likely to jam the card reader. If you look at that decoding table Dee shows, you will notice that even though that type of card has 12 rows, which gives you a theoretical 4,096 possibilities per column, there are only 64 characters in the table. This allowed them to create a code that would keep the holes well spread out.
@@fllthdcrb I worked with punch cards in my early years, so I know too many holes makes a punchcard into a “lace card”. I’ve turned on the option for the mainframe to punch out an object deck and there were definitely more holes.
But you’ll note that there are only 72 usable columns on the 80 character card. The other 8 are for special codes (known as Hollerith codes). 80 works quite well from a binary point of view (64 + 16) which may have been more of a factor.
I used to work for a company that had 80 columns as part of their coding standards, in the 2000s! I complained saying we're never gonna punch this out on cards! To no avail of course.
@wmrieker I had to write some cross platform C in the mid 2000s for a bank. It had to be able to run on IBM mainframes among others, which meant the code was constrained to 72 character lines and had to work with EBCDIC as well as ASCII. It still hangs about today.
@@stevetodd7383 In 2021, it emerged that a Belgian bank was still using EBCDIC. A customer complained after the bank omitted the umlaut in his surname, citing GDPR’s right to correct inaccurate data. The bank argued its EBCDIC system couldn’t handle diacritics or lowercase letters, but the appeals court sided with the customer.
@@stevetodd7383 I first used punch cards in 1972 in college for my FORTRAN class. All 80 columns of the punch card were physically equally usable in the keypunch machines and the card readers. All 80 columns used the same Hollerith codes. As seen at 11:31, by convention, columns 73-76 optionally contained a project label, and columns 77-79 optionally contained a sequence number in decimal. Typically, column 80 contained a blank or zero, but it could have a digit if you wanted to edit the card deck by inserting a card and still have the numbers in sequence. In case the card deck was dropped, in theory the sequence numbers could be used to restore the cards to the correct sequence manually or by using a card sorting machine.
My first job in flight simulation was working on and programming simulators from the mid 1960’s. They used a DDP-124 computer, 24 bits 32k RAM. We had all the original punch cards that came with the simulators and still used them to update the radio database, until I found an easier way. After we made any software changes we would create a new load on paper tape. Paper tape was faster to read and if you dropped the spool all you had to do was rewind, not sort. Eventually we modified the computers to use an IBM computer to load the program directly into memory using the DMA bus, so paper tape was only used to create software changes. A skilled programmer could read the paper tape and correct any errors that the 30 year old puncher created. I am enjoying this trip down memory lane.
If you notice at 11:10, there is a diagonal marker line across all the cards. This helped with re-sorting in the unfortunate event that the stack of cards got dropped. It's a quick way to initially re-sort the cards.
This is why explicitly numbering lines in BASIC was such a brilliant idea at the time. I don't know if the original compiler could ingest code out of order, or if it was just for programmers' benefit, though.
You may have noticed on the far left side of these cards, there are a numbers of cols unused in this example. Those were for sequence numbers. COBOL in particular used cols 1-6 to store the sequence number which will also get keyed by the keypunch operator. Then if the deck of cards containing your source program was dropped, you could feed the unsorted deck thru a machine called a collator to get the source deck back into order. That in and of itself was a time consuming process, and you could do a video on how the collator worked. Suffice it to say, it provided for getting an out of order deck back into order. Love these videos!
@@mdn8rdr5903Also in columns 73-80. The earliest computers for which FORTRAN was designed had readers that could only read 72 columns, so the last 8 were reserved for sequence numbers. That way, if they were dropped, a few passes through the card sorter would put them back in order. This was such a good idea that even for computers that could read all 80 columns, language designers started to reserve the last 8 columns for sequence numbers.
There were sorting machines that could read a column and put the card in that numbered bin, you then collected the bins into a single stack. By repeated sorting on columns you could sort a deck of cards with this.
@@mdn8rdr5903 Thanks for the info, I was wondering if they didn't already thought of a machine to sort the cards, in case of accidental mix-up, because just making a diagonal line by hand with a marker, seemed like a very error prone system to me. And if you can make a complex card reader, you can certainly make a card sorter as well.
When I got my computer science degree I used cards. Dropping your cards stacks with ALC (360 Assembler language) was an amazing problem. Built using ALC 360, Fortran, RPG and Cobol. In Cotton processing, cards were used to track cotton bales for managing gin cards and compress cards and the USDA issue classification cards. The cards represented ownership. After the 80 column cards, we used 96 column cards, which are smaller. Later I worked for IBM for 30 years.
Yea... that was surely one way to ruin your day. Fortunately when I was doing Fortran in school I never dropped a stack... can't say others in the class were as fortunate. 🤭We started with the 80 column cards and switched about 1/2 way through the semester to the 96 col cards. I don't ever recall seeing the small cards in use out of class... where the large cards would pop here and there for billings in the mail, etc for several more years. I don't think the small cards were ever widly used much and not for for very long.
When I was going to a 2yr tech college, a fellow student found out the hard way why it was a good idea to punch sequence numbers into the cards! Ahh yes, the 96 column cards the System 3 used, along with RPG!
I learned basic programming language at collage in the early seventies. I wrote the program on a piece of paper which I gave to a gui who punched the code onto a paper strip. The paper strip was used to send signals over the phone to a central computer somewhere. 4 days later I would get a printed paper back with a lot of question marks and gibberish. To me the zx spectrum was a revolution. With instant feedback i could have some fun programming.
I have done it all. As a prototype tester I keyed small binary programs in the computer main memory and afterwards I punched it on paper tape to reuse it (1970/71). When I changed to OS programming I used punch cards (1972) for a short period, then the ASR 33 Teletype (1973) and a 24x80 CRT display (after mid 1973). I used assembler for IBM 360, PDP 11, P800 Philips mini computer (1980) and P1000 Philips main frame (1970). From the programming languages I used mainly PL/1 and RTL/2 (a UK language comparable to C), but I learned Fortran, Cobol, SQL, C and Clipper. SQL, C and Clipper I used occasionally. I stopped programming around 1985, because I made a career as chief architect and department manager.
I used Hollerith punchcards when I was a student at Georgia Tech. I learned read the holes. I used that ability to astound my fellow students. The first card in a card deck included the user's name and password. You were supposed to put a blank "cover card" to hide the first card, which usually had the text along the top with the user's info. Often, students would skip the cover card and black out the text (or if they were savvy, they'd turn the print function off on the key punch). I would chastise others, about the missing cover card, rebuke their protests, and announce their username and password, to their amazement. This was made easier since a great many students used GATECH as their password.
I started my coding career in the 1970s. Card punches were everywhere, and I got very good at using them. Then came a day when I used a card punch machine for the last time, and I felt... the same as any day because I had no idea it was the last time, just as with so many "last times" as you live your life... The last time you rented a VHS at a video store. The last time as a child that the whole gang played together. The last time you mowed a neighbor's lawn to earn some cash. The last time you played a physical CD in a car. The last time your child asked to be lifted up and carried. There must be many more that I don't have time to write down, right now. BTW, this post was inspired by something I read recently, but I can't remember the source. It was a good read that I wish I could find again.
I was a programmer in the 1970s and I've punched a lot of cards. Dropping the card deck was a bad day. I had so much practice that could read most cards by eye - which was handy when the "human text" was missing. There was also an End Job card as last card - if you forgot that the machine would read your entire deck then reject it and move on to the next job. Also there was no "backspace" on a punch machine - one slip and you would have to bin that card - and if you forgot to remove it, it would end up in your deck, which would then fail. Thanks for an excellect overview of this long forgotten tech.
I remember editing programs on punch cards. You would duplicate the line with the card punch machine, then type the correction which would replace the characters. You could insert characters by holding the left card (card being read) and typing. You could delete characters by holding the right card and pressing space to advance the left card. It was also cool to make cards where the holes represented letters (think dot matrix)
Fun fact: there are more (a *lot* more) ways to punch a single punch card (2^960) than there are atoms in the entire (observable) universe (~10^82). I still can't quite wrap my head around this!
Punch cards were used to enter keying material into old Kw-26 crypto machines in the past. We used decks of them to get crypto sync up with distance communications circuits in the Air Force in the 1970s. Decks were kept in crypto vaults in the crypto room behind cyber-locked doors. The decks were transferred to end stations under guard at that time.
one card was one 80-character LINE in program and it was useful to manually write number on each card, to maintain order in deck, if you accidentally drop it on floor
You seem to be referring to the number of possible combinations of holes punched/unpunched in one of those 12×80 cards. But please note: the vast majority of those combinations would be unusable, because punching too many holes structurally weakens the card, which can cause it to jam the card reader. That's why, despite each column having 4,096 possible values, you will note the table we see in the video only has 64 entries.
I was THERE. Using punch card machines to program FORTRAN. Nothing like waiting in line to use the 4 punch card machines in the computer room. We had programs that were a quarter box of cards, a half box of cards and a full box of cards (or even multiple boxes). I believe it was about 2,000 cards to a full box (they are 0.007 inches thick). After the cards had been read into the card reader a number of times, they started to get worn and you would add a command to your input to duplicate your deck using new cards. I programmed on a Control Data Corporation computer running first the SCOPE operating system and then the NOS/VE operating system.
I started programming Fortran on a CDC computeur in 1966. Frustrating that, when you start programming, you put your cards in the box to be processed and you would get the results in the morning: syntax error! This was at Polytechnique Montréal, school of engineers.
@@pierreforget3357 I started at AiResearch in Phoenix in the spring of 1977. Before the company had its own computer, the engineers before my time (late '50s or early '60s) DROVE their card decks 5 miles to Arizona State University to be run!
@@mattevans3511 One of the more experienced programmers taught me how to decipher a core dump. Pretty primitive stuff. As I recall, you could figure out the line of code where it crashed and then work your way through the various operations on the line to figure out just which one caused the crash. Visual debuggers (which came MUCH later) were such a boon.
@@mattevans3511 Yeah... a big printout of the green / white line tractor feed paper with the prgram, data & memory dump. Then you have to pour through the stack of paper trying to find the bug. Thing with programming with cards is a bug could be something unrelated to logic. Could have been a typo where there are no spellcheckers or compilers to flag errors or it could have been forgetting to put a control card in the stack. It could also be tedius punching the cards... if you made a typo you'd have to trash the card and repunch. I was actually glad (at schoool) when we switched to learning APL on the IBM terminal. No more punch cards. Yay. Although that in itself baffles one's mind today... we had a workspace of only 22K!... 44K if you chose to use the backup space as additional workspace.
02:42 suddenly, Pesto got into the video, sure this pinguin is going to places, BTW: Pesto is molting now, into his black and white fur. This is probably this is folklore: at IBM somebody was explaining a punch card, when an IBM engineer walked by, joining the lecture, grabbing a piece of paper and a pencil, using the pencil to punch a hole on the paper: Ladies and gentlemen, this is a punch card. I was thinkin about music, and those old pianos with a rolling piece of paper with holes playing music; they did not make your history. Great content Dee, I love it, keep producing them, cheers.
Brings back memories of my first trip through college. Took Fortran IV using punch cards. My biggest take away was to make sure the deck had a !EOD card.... If not, your cards and green bar paper would be no where to to be found. Asking Bob the computer guy for them was not advised since the computer would have to be unplugged and Fortran had to be reloaded.
X and Y not marked because everyone knew exactly what they were; 0-9 a little trickier. Most cards that I worked with were entirely unmarked: We just trusted the key punch operators. Besides, the top-line was usually legible. First thing you did with your deck was just printed out on green-bar (133 column x 58 line alternating dark and light green paper) so you desk-check it and resubmit correction. Late 1970s we graduated to terminal entry.
Row X and Y were unmarked to allow printing of the characters on the card using an IBM 557 Alphabetic Interpreter or IBM 552 Alphabetic Interpreter. The IBM 557 translated holes punched in cards and printed the corresponding alphabetic, numerical, and special character data on the face on two lines: one line across the top of the card and one line between the Y and X punch rows at a rate of 100 cards per minute at 60 characters per line. The IBM 552's speed was 60 cards per minute.
EBCDIC - Extended Binary Coded Decimal Interchange Code (later on microcomputer replaced with ASCII - American Standard Code for Information Interchange used where characters were represented for English and European based languages). With the rise of the Internet, it became necessary to represent languages that were phonically or symbolically displayed. Unicode allows for most of the worlds languages to be represented.
Yep, the fun part was moving EBCDIC formatted data to ASCII. Programs would fail as the two systems had different sorting sequences, you would get data errors. I had seen this before and fixed it when replatforming an application from an IBM mainframe to an HP system. Years later I managed a team who were doing something similar and we ran into the same problem. I gave the team one day to figure it out. In the end I had to tell them how to fix it. Fun days.
„replaced“ is a bit misleading. It is still used on mainframes (360 inspired ones /360,/370,/390,/z,…) and it only feels like replace, because all the „smaller“ systems (unix-like) just have expanded so much. IBM would for sure severe issues if they would replace EBCDIC with ASCII in their mainframe operating systems. And they are still the ones starting a partition running one of the hundreds Linux instances, that share one heavy box.
Oh, my God! I've been into programming for over 3 decades and surely have heard about punched cards. This video however first time I ever got to learn how it's applied to program computers in the past. Thank you so much. I will also checkup the link in the video description.
Columns 1-5 are for a statement number. Fortran before f77 version required the use of go to statements so if you wanted to branch to a statement it had to be numbered. Column 6 is a continuation flag. Anything punched there except a zero indicated the statement was a continuation of the previous statement. Columns 7-72 is where the code statement goes. The remaining columns were optional card numbers. If you filled in card numbers and dropped your deck you could take them to the sorting machine and recover.
Oh yeah. I had a retired Army programmer teacher (read: former electrical engineer) who told me his old office staff included a person whose job was only keeping track of those cards, numbering and inventorying them, maintaining their quality, and so on.
One quick method was to use a black marker to mark some design, or even just a diagonal line, on the edge of the deck. Reconstitute the line, and you've got the cards in order.
@@justliberty4072 This is before my time, so I never experienced this personally, but that diagonal line system, seems to me like a potentially error prone system, is better than nothing yes but in my mind, depending on the thickness of the deck and the angle of the diagonal line, it would be very easy to mix up two very similar lines, created next to each other, as they could only differ by a millimeter or less. IMO numbering them would be a way better system and based on other comments, a machine existed to sort them, by using info punched in the cards itself, but this last one was probably only used by companies, not individuals, as that machine was probably not cheap either.
If you had access to a card sorter you could punch the card numbers in the last few columns of the card before dropping them. Then feed the scrambled cards through the sorter a few times to get them all back in order.
After my dad got retired from the Army in 1986 he went back to college to get a degree in business management and one of the classes he had to take was a computer programming class in COBOL. I helped him with the class and they were using punchcards and batch processing for their programs and I was surprised that is 1987 they were using punch cards.
To be technically correct, the Assembly Language is a low-level language, as this is just a symbolic notation of a machine code. It does not require a compiler, and it is absolutely hardware-dependent. Thus it is very different from Cobol or Fortran, which are high-level programming languages.
To be technically correct, Assembly language IS machine code. As you state it is just one of many ways of encoding the patterns of electric voltages recognised by the computer as representing individual instructions. Binary, octal, decimal, hexadecimal, assembler mnemonics, True&False, High&Low, or any other method of storing an individual machine instruction as an arbitrarily agreed group of symbols. An assembler is simply a symbol translator. Admittedly an assembler can include functionality to make life easier for the programmer such as replacing mathematical expressions or label references with the resulting values but that is no different to the programmer using a calculator, look up table or manually calculating the result themselves. In the end an assembler does nothing but translate the source code into individual instructions, specifically selected by the programmer for that particular processor. High level languages (compiled or interpreted) however, produce 'groups' of instructions, chosen by the translating program based on its understanding of the programming structures used by the programmer and its own previously selected usage of processor resources such as registers and memory allocation. All compliant assemblers for a given processor will produce exactly the same set of instructions given the same source code (assuming it doesn't contain any non-standard assembler directives) whereas it will be VERY unlikely for a compiler to produce the same output for any non-trivial code, even if the resulting machine instructions do produce the same overall result using an alternative method.
@@MikePerigo Yes, Assembler is just the machine code, but especially on mainframes, they have macro-assemblers, that are allowing you to define your own language within. Their features are way beyond what a PC macro-assembler would provide.
@@fromgermany271 Macros are just pre-written assembly code snippets written or selected by the programmer. Admittedly professional assemblers have more bells and whistle features than basic offerings, such as conditional assembly and lexical replacement facilities but any assembler only produces output containing the exact instructions chosen by the programmer. Any code generator that automatically produces code containing instructions not explicitly specified by the programmer, variable allocation, memory management, bounds checking etc. is no longer an assembler but a compiler or interpreter. Even low level languages like APL or PL/1 allocate memory based on internal rules rather than the programmer having to make those decisions.
@@MikePerigook you are hurting me. No assembly language is machine code, all of them went, and still do, go through an assembler to generate the machine code. In almost all cases if you were programming in direct machine code, if you were lucky you had switches, if not, get out the wire warping tool. I did all three, and as I learned not all that long ago, I still remember the bootstrap switch sequence for an LSI-11 (as the tech on the other end of the phone was reading me the settings I realized I had already rebooted the electron microscope by finger memory). I’m sure I’m not the only one here who could do similar on any PDP, IBM, UNIVAC and others.
@@jlholmes8 I don't disagree with that. I agree that true machine code is a sequence of electrical signals that the processor acts on. The point is that in order to generate those signals the desired instructions have to be encoded in some form and stored in the memory. The input method and choice of symbolic representation are immaterial. Whether you use switches, lasers or plain old copper wire to transfer the instructions chosen by the programmer and eventually stored in memory they have a one to one relationship. An assembler is just one of many encoding schemes that can be used. Unlike languages that generate code in line with a programmers desires an assembler literally just translates an encoding method on a one for one basis.
First, I learned typewriting when I was 12 years old in 1965. Then my typewriting skill enabled me to learn card punching in 1972. I worked on the IBM 026 Card Punch machine and the IBM 024 Card Verifier. I was able to make program cards for operator use. Then, I foolishly left my first job to take another job as recommended by an employment agency counselor. At the second job, I used the IBM 029 Card Punch machine and the IBM 059 Card Verifier. Also, I gained exposure to the Entrex Data Scope, a data terminal with a keypunch-like keyboard. In 1979, I worked on the IBM 3742 Dual Data Station and occasionally on the IBM 3741. I began to lose some flair doing keypunch, because data from the source documents were predominately numeric and nil to no alphabets. I feel satisfied that the microcomputer with the 104-key keyboard changed the way business documents would be made. Your show impressed me very much.❤
One thing is that early monitor displays had 80 columns x 25 lines. This was to accomodate 80 characters from the punch cards and the cards were grouped in 12 cards, making two sets for 24 lines and one extra line to input commands. When the first IBM PC DOS marchines were produced they kept this format, that endure up to Windows XP, later in Windows Vista it became 80 x 50. Later versions got rid of the 80 columns limit.
There was excellent documentation on all aspects of Holerith cards. The way they were read was standardized, but not always used. Since the cards were used for tabulation initially, the encoding you mentioned isn't always used. My favorite use was to vote. In California we used Porta punch devices to knock at one hole at a time to vote. Each hole represented a choice. A card reader simply counted up how many of each hole was punched. To prevent overvoting, when the card was read, if 2 votes for the same office was punched, a program would treat it according to local law. At large corporations we rarely punched our own cards and sent forms for professional key punchers to punch. Once we got IBM 3270 with TSO we did most programming on screen.
The top three rows on a Hollerith card are for the zone indicators used for entering alphabetic information, usually referred to as 12, 11 and 0 rows. Row 12 plus a numeric 1-9 encoded A-I, Row 11 plus 1-9 encoded J-R, Row 0 plus 1-9 encoded /-Z. Numeric data was encoded with rows 0-9 punched without a zone punch (except in a numeric field an 11 punch in the units position indicated a negative number). Special characters were encoded with the addition of an 8 punch in addition to some of the alpha characters.
I learned both languages in the late 70s. The punch cards were gone from my life by the mid-80s. I stopped coding in IBM assembler in the 90s, but still used PL/1 until I retired in 2015. A great language, that PL/1.
It was so painful having to type those cards out. You would make a mistake and have to eject the card and start over. Then they came out with punch machines with a display that allowed you to make corrections as you type and only when you were satisfied with the line did you push a button to have the entire card punched. As a teenager I got a kick out of listening to the sound, especially when some machines were still the punch as you go vs the new ones with displays. You would heard punch, punch, punch (at a slow typewriter speed, trying to avoid mistakes at all cost) from half the room and the other half was like listening to a machine gun firing. LOL
Another good video, Dee. Fun fact there was a punched card system still in use in the UK right up until the 2010s! Punched cards started to be phased out as higher level programming languages came to be created in the 1950s and 1960s. Another name you will be interested in is Kathleen Booth, who invented assembly language in the 1950s. She also wrote one of the earliest programming books for assembly programming.
Misery was feeding your big deck into the card reader and then hearing a sickening crunch as a card got jammed and shredded inside the machine. Usually caused by cards that were bent or misshapen by being read too many times. At that point you had to determine which card got mangled and re-key it and try again.
my fist programing was on a terminal in Charleston SC while I was learning Fortran 4 in 1976. It was using the "Punch Cards" and the assigned program was to Solve a Quadratic Equation. Of Course, one of the Feared outcome of running the program was that the output was on a printer and have it in a infinite loop. If always amazed me that my program was about 30 punch cards and the Cabal programmers' cards were 100 or more. Then when I started programming in DBase3, I learned that Database programs are much longer because of the size of matrix of Columns (Fields) and Rows (Records). I also took a course of Assembly for the 8080/8085 microprocessor in 1984. I saw my first CNC type machine in 1967 while working in a Manufacturing Plant as a Lathe Operator. The, I never used it or saw it run, CNC machine was a small Mill and was run using IBM Punch Cards, Programed by Engineers. This type of history is base level, like the Loom you started with.
Dee this is great. I remember my father working with punch cards and I had always wondered how they work. This is the best explanation I've seen/heard/read. Thank you!
Hey Dee, wow, you are such a great communicator. Your obvious technology background, easygoing manner, body language, and speech patterns, make for such interesting listening. I like your use of graphics ( and introducing your dog!) . Please keep up the great work as you as a special person who has found their niche. Bruce from Australia
The keypunch machines had several cool features. The card you just finished moved to the left where it was being read by the machine. Sometimes you could press a certain key on the keyboard and the card you were working on would copy the character of the prior card. There was also a rotating drum up and to the left; you could open the door, remove the drum, put a card onto the drum, and the holes in the card you put on the drum would instruct the machine to for example skip the first 6 columns and start in row 7 (handy for Fortran at the time), or when you get to column 10 copy columns 10 through 20 then eject the card. Most didn't know how to use the drum cards, but knowing that did save quite a bit of time depending on how repetitive your cards were. Another invaluable machine was one where you fed in your deck and it would print out what was on the cards. Great for debugging and making sure your cards were in order. Some key punch machines did print the line of code at the top of the card; but some didn't.
In 1975 on the IBM 360 in college you also needed a Job Control Card which was sharp corner rectangular. It told the Reader/Computer that a new job was being run. That way the billing for the computer time use could be applied to the correct account. Fortran programs were often only run in batches when enough jobs were waiting for them to load Fortran into the computer. When I had a typo in the card deck and had to retype the card and rerun my program it could take a day. I tried to shorten it by having a small deck of Job Control Cards to have a dozen or more jobs that basically started then stopped doing nothing in between. That would increase the count to get the batch to run sooner. Then the computer crashed for half a day twice. When I came back in to run again, they said "You're the guy!" Apparently since most jobs were by researchers with decks a few feet thick, the accounting was done in the background. But IBM discovered my trick provided a new job faster than it could bill the old one, causing those crashes. They modified the handling of all jobs to add a small delay to allow for the accounting before proceeding with reading the next job. Thankfully because I had not caused the crashes on purpose, they didn't kick me out off the computer.
The code also doesn't use all 12-bit space available, instead preferring codes with fewer holes, especially not adjacent holes. And I just now realized that putting spaces between tokens improves the integrity of punch cards. 4:40 The correct transliteration is Semyon. The accent is on the second syllable
I took Fortran programming in 1977 at the University of Alabama in Huntsville. We used punch cards. It ran on a Univac 1100/60. The University made LOTS of money allowing time sharing on this main frame computer by allowing the local defense contractors to run programs on it. A BIG program, carried around in boxes was about 1500 lines of code. It was about this time that the keypunch machines were upgraded to NUMBER the cards. That way if someone dropped a deck of cards, a sorter could be used to reorder the cards. Another Huntsville first was it was home to one of the very first COMPUTERLANDs. They sold kit computers that you had to assemble yourself AND they sold programs on paper tape. I replaced a MUSEUM quality teletype terminal with an HP-85 in about 1984? at the hospital that was running a piece of medical diagnostic equipment. Things have come a long way in a very short period of time.
My, recently concluded, 45 year IT career started in 1979 as a computer operator on ICL 2900 series hardware, my first 2 programming languages were COBOL & ICL PLAN Assembler both learnt, by trial-n-error, on the midnight shift as an operator with all my programs written on punch card (courtesy of an IBM 29 Punch machine) I finally junked the cards in 1996 when I moved to Denver Colorado. Given my typing skils, I have to say, I dont miss them! Afterthought! I just recalled something I learned back in 1979; the punch card is the most inefficient form of data storage ever invented. This is because all the data is stored in the holes, the card is only there to hold the holes in place. The card is therefore 100% redundent and carries no information.
The blank column is dependent on the programming language, but can represent that the data typed on the line is not to be executed (a comment) OR that the line is or will be a continuation from another line. Continuation in FORTRAN would be rare (and likely not a good idea), however lines in COBOL could get quite lengthy and continuation might very well be necessary.
Back in 1977 I wrote my first program using Punch Cards on a DEC PDP11/04 while in High School. We also created Student Records on Punch Cards. Each punch card contained several fields of data which were controlled by a coded punch card that wrapped around a drum inside the the key punch machine. Keypunch machines were no joy to type on. To get the cards in a specific order had to be run through a massive sorting machine with a bunch of cables connected to hubs in the machine to determine how they were to be sorted. Its been a long time just the way I remember Alpha Numeric Data was by remembering J and R. Numbers were simple just one punch on the line to get 0-9. Letters were required 2 punches per line one at the top of the card and then a punch on 0-9 to get the letter. There three lines at the top one line and a number would represents letters A-I the next line would represent the letters J-R and the last line for S-Z . That's all I recall about the 80 Column Punch Card. Then we got to play with 80 Column Mark Sense Cards using a #2 Pencil to create the marks which replaced the holes. I never got to play with the 120 Column Cards but as more of that PD11/04 became functional we got to play a CRT Terminal which was a money saver because Hard Copy Terminals just wasted paper.
Thanks for your great work! However, I just want to point out one more thing. A program consists of algorithms and data structures-in your words from the Apollo computer film, instructions ("verbs") and data ("nouns"). Initially, machine instructions (like on Jacquard’s loom) were "embedded" within the machine’s structure, while input data-like which threads to shift-were provided via punched cards. The output data was processed directly into analog output signals. Similarly, in music boxes, music was "encoded" onto a cylinder, and the code was "hardware-translated" into sound. The same goes for the telegraph and teletype, where data was recorded on paper tape for later transmission or reading to streamline the process. The 'instructions' controlling the operation were 'embedded' in the construction of the machines. Maybe it would be worth making a video about the history of perforated tape and teletype? The first applications of cards and tape were for data storage. A true breakthrough happened when Charles Babbage and Alan Turing suggested that program instructions should also be treated as data for the machine, allowing not just data but also instructions to be recorded on cards or tapes.
@boguslawszostak, it has been suggested elsewhere, that the earliest programming algorithms were instructions on how to knit a garment. Knitting instructions can include subroutines and functions with replaceable arguments, conditional loops, and all the basic ideas we can find in early programming languages. -toby
@@tobyr21 There has been a misunderstanding. The key point is that the earliest weaving machines didn’t really have "instructions" as part of their programs; instead, the "program" consisted solely of an encoded "pattern," which is to say, data. The way they operated was entirely determined by their physical design. This is easier to illustrate with a barrel organ. On the drum, there are holes, and the whole mechanism is only capable of triggering a sound "through hardware" when a hole appears on the drum. The machine can only convert the sequence of holes, in a fixed order, into a movement that produces sound. Therefore, there are no "instructions" explicitly written anywhere; they are embedded in the machine’s design. In Jacquard looms, the holes merely conveyed the positions where the loom’s components should be set according to the specified pattern.. The true breakthrough was the realization that instructions-what the machine should do, rather than just the data it operates on-could themselves be treated as data.
@@boguslawszostak1784 I'm not disagreeing with you. I'm just pointing out that knitting instructions can be, and were, even in the 19th century, complex algorithms with the essence of what we recognize as programming. -toby
I started with punched cards in 1975 on an ICL 1903a running George 2+. Sometimes we would use a hand punch machine. The other method was paper tape. The old definition for Turnaround time was the time between submitting your cards and receiving the remains. At least coding changes where replace a card. I do remember my dad taking me to NatWest Bank’s computer centre in London and setting me up to run one of the first IBM 360s in the country to do tests using punched cards to tape whilst he and his colleagues fixed some tape drives.
Calculators, tabulators, etc were programed with "program boards" that were essentially patch boards using jumper wires to "process" the data on punched cards prior to the GP computers. Yes, I'm old enough to have seen them at work. SAFETY TIP: Do not wear neckties tied around your neck, only clip-ons. Unit record devices WILL confuse the end of the tie for a card long enough to cause, at a minimum, a Workers' Compensation case.
Another thing that's pretty funny here is that dropping a deck of cards was pretty rare, and usually harmless because of advanced rubber band and cardboard box technologies. 😉 You were much, much more likely to screw up unnumbered cards while trying to edit. For example, refactoring duplicated code into a subroutine typically required either a large workbench or using a bedspread as a makeshift workspace. Unfortunately, few programmers had cardpunches inside their bedrooms, so whatever large surface nearby the "computer room" would be used. I remember a colleague explaining he'd use a gymnasium floor, but once had his work destroyed by editing too close to a door on a windy day opened by surprise. A few CRTs were available for editing long before punchcards stopped being the mode of initial program coding.
@@jsalsman tripping on the stairs with two made me really glad only two rubber bands broke. I think each were 50. Sequence numbers saved more than just me.
Ms Dee, until I just watched this, I had never heard of “punch card programing”. As a nit pick, Hollerith cards were/are (yes the are still in use) not paper but a very thin sheet of cardboard (my uncle made them for IBM, who then resold them to everyone. He saved me a lot of computer funds in college) or later vellum like “paper” tape (also still in use by a not-so-small international in midtown Manhattan). I never realized though the loom was the first punch driven (I can’t say programed) device, I had always thought the player piano was. Thinking about the loom though, while not cards but paper tape, high speed band printers used basically the same technology. It does make sense as I now think about it. I wish I knew it in the 90s when my assistant/operator would ask me every month at billing time “who came up with it’s , it breaks every two hours!! I don’t think I ever told her how often grade statements ripped apart the ribbon and trashed the band at the same time. Sort of high speed laser printers (five for the price of a one year maintenance contract) paid for themselves just on the overtime every month. Someday I should write the 70s through 2000 memoirs of real-life computing.
Thanks for bringing up memories of my youth! In early FORTRAN versions, the statement started in column seven and ended at column 72. Columns 1-5 were for statement numbers - labels for GOTO's. If any character was in column 6, the card was interpreted as a continuation of the previous card. Columns 72-80 were for identification - you could number them to help out in the case of dropping the deck on the floor (not that it ever happened to me ;-). It was painful to make these cards as one mistyped character would make the card useless. I wonder how many of the 10 million cards per day created were later used to make Christmas wreaths.
There was another form of programming for punched cards that was used on card processing machines such as IBM 407's (tabulator) and IBM 82's (sorter). These were programed by hand wiring boards that were plugged into the machine which changed the circuitry of the machine. The 82 series of machines could sort on any combination of columns and the 400 series of machines could interpret the data on the cards and print reports such as tabulating columns.
Fun fact: When I learned COBOL in college in the early 90's if you had to write a statement in multiple lines, the second line had to start 4 spaces in (B section). The reason is that in the days when the dinosaurs roamed the earth and you wrote your code on punched cards, the way the parser understood that the statement continued in other cards was with this indentation and that was kept even when you wrote code on a text editor
Like many commenting here my career started in this way. Our coding sheets were sent off site for punching (actually in a different town). It was typically 2 weeks until you were able to test your code when the cards returned. An instructor at the company I worked at , supposedly coded a program with 2 statements per line, using a GOTO as the second statement on every card. As the story goes if the card stack was dropped by an operator, only the first and last card needed to be correctly placed for it to work correctly!
row 6(?) is used to indicate that this card is an appendix to a previous card. this enables program lines with more than 72 characters. i hope i remember this correctly. i used it last time in 1985. The first seemling unused rows are meant to contain Format-instructions for inputs and output commands. Thank you very much for this video, love it
I started programming with punch cards in 1966 on an IBM 1620, first with machine language, then with assembler (SPS on the 1620), and then FORTRAN II. I later moved to the university's IBM 360, and later after a stint in the Army to an ITEL AS/370 (NOT Intel), a clone of an IBM/370, all with IBM FORTRAN IV G and H. For my graduate research I read some of the data I needed from Sandia Laboratory microfiche reports to punch them onto approximately 4000 cards, then had to check every card to make sure the data had been transcribed correctly. After beginning work at Oak Ridge National Laboratory in December 1978, I continued using punch cards there until sometime in the late 1980s when we finally began using personal computers as terminals to connect to our mainframes or Unix workstations.
The best punch card story I know I heard from a complete stranger in a Mexican restaurant in Las Vegas in February 2008. I was waiting in line to grab a bite after visiting my wife in the hospital. Strange as it sounds, somehow the conversation with the woman ahead of me turned to old computing and punch cards. It turned out that both she and her husband were in the Army during the Vietnam war with her having an assignment stateside and her husband was in Vietnam. Both were in administrative units handling logistics and had cause to transfer logistical data back and forth between their units using punch cards. So they starting writing each other lettters using punch cards but turned off the printing on the keypunch so no one else would figure out what was going on. When one received a box of cards from the other, the recipient would run the blank cards through a card duplicating punch, but with the printing turned on so they could see what had been written. I thought it was quite clever.
When it came to getting data into early computers, punched cards had a similarly low-tech competitor: punched paper tape. Borrowed from use with teletypes, you had a long strip of paper with holes punched into it to encode characters as used by the teletype systems of the day. Many early computers had instruction sets that were designed to be easily encoded on a teletype, and word sizes that were multiples of the 5-bit teletype character size. Australia's CSIRAC being one such example, using 20-bit words.
When I was in college, there was a desk sized card punch machine in the corner of the room where we went to pick up our print jobs. Students used to sit on it while waiting for their jobs to finish. One of the grad students told me that it hadn’t been used in a years, but they couldn’t remove it because it wouldn’t fit through the door after some remodeling of the area.
When I was young, we sent off our punch card deck in Fortran or Cobol to be processed on an ICL mainframe, You had better not have forgotten the George 4 Job Card! We didn't even have modern punches, you had to know the rows in each column to punch for each character and press the right combination of keys.
I learned my first programing language (Fortran IV) using punch cards. I would write the code on a pad of graph paper, using the first 80 boxes as columns. From there, I would type the code on an IBM card punch machine which was similar to typing on a PC in and IDE. Only there was no color coding, auto tabbing or dropdown menu selection boxes. And no lowercase. The 'stack' of cards as we called it, was much like a computer stack in ASM, lol. It had all the cards in descending order: first card (code line 1) then card 2, 3, 4, etc. To accomplish this, the stack was in normal descending order as you would expect, then the entire stack fed through the card reader upside down. The exception was that there was two stacks of cards: the program stack and the data stack. The program stack would be fed in first, then the data stack next with the first card being the data stack identifier for the computer to understand that the following cards were the data and not interpreted code. The computer we used was the IBM 360. After the code was run, you would get an 80 column wide dot matrix print out of the results. Usually, it started with the code then the printed data stack and then the dreaded line that read something like, "SYNTAX ERROR LINE 234. EXECUTION TERMINATED. Yes it would scream that at you because, again, no lowercase! lol You would then have to go figure out what the error was. It was not always on the stated card because it could have been a logic error on a previous card up the stack. Normally, it was that exact card and you just simply re-punched it and replaced the faulty card and ran it again. Hoping you would not get another syntax error further up the stack! It was the best time of my early programming life and I would not want to have changed it. You learned so much about computer science while learning to program. A few years later we went from punch cards to timesharing terminals which was also load of fun! :)
1970. I lived in the dorm so I had access to the punch card machine and the computer office at 2:00 AM so I could get access. When you retrieved the cards from the cardbasket, you immediately rubber banded them so that if you dropped them they would not spread all over the place. If you did drop them, it was easier to re punch rather than trying to get them back in order. You would type very slowly and carefully because there was no going back to correct a mistake. Now, as a hobbiest, I use Thonny for my Python and micropython.
I went to George Westinghouse HS in Brooklyn NY next door to Brooklyn College. Our HS Computer science classes used the IBM mainframe in the college. It was awesome. The first computer i programmed was with punch cards. 1973
As a PhD student in the mid '70s one of the other PhD students, a rather clumsy fellow, wanted to use a programme on a computer at Cambridge University to process his data. He put his data onto a few thousand punched cards (punch is not an adjective) and went off by train to Cambridge. The inevitable happened: he tripped and scattered the cards across the railway carriage. He had not printed sequence numbers on the cards, so could not feed them through a sorting machine.
I once worked for an organisation that had its head office and data centre in one place, and some of its customer service offices in a few neighbouring towns. One of my former colleagues there, whom had worked for the company for decades already, told me that he had once been asked to drive a van from the head office to one of the customer service offices to collect some punch cards. So he did, and once there he just carried several boxes of these cards into the van and started heading back. As he was driving, he looked in his rear-view mirror and was horrified to see pieces of cardboard flying in the air behind the moving car. It turned out that, of course, he had forgotten to close the back doors of the van properly, so some of the punch cards had flown out. He was convinced he had just caused a major problem - and, indeed, he had!. Luckily, though, no one on the scene had really understood what had just happened. So he just did his best to collect the cards from the street and drove off without much notice or consequence. I guess people didn't care much about data safety back then... And I guess we haven't learned too much about it ever since :D.
Fascinating, as always! In my past at the University of Vienna, the machine (CDC Cyber 73) had the opportunity to number your cards sequentially in the first columns, giving away some space for code. The deck always started wth control cards, stating the operatig system, the compiler,... , and an optional sorting command. If you dropped the shoebox with your cards, you could just feed the mess in any order, and the machine did the sorting before execution in memory (or possibly hard disk). With midframes, such as the PDP-11, we used teletypes and the waxed stripes with the holes, which already was ASCII. The PDP-11 was a very common machine in scientific data acquisition, and in the 70ies we had Textronix monitors with already 4096 x 4096 resolution, which of course was vector graphics. But that is already off topic :-).
The last year my college used a punch card computer was in 1985 - 1 year before I went. They sold that system in 1986, when I was a freshman. My grandfather was an mechanical engineer and one of the patents he received was for a machine to electroplate silver traces on a circuit board 1/64 of an inch high by 1/64 of an inch wide and was controlled by punch cards. This was used to make some circuit boards used in some of IBM's computers.
14:25 Row X and Y were unmarked to allow printing of the characters on the card using an IBM 557 Alphabetic Interpreter or IBM 552 Alphabetic Interpreter. The IBM 557 translated holes punched in cards and printed the corresponding alphabetic, numerical, and special character data on the face of the card on two lines: one line across the top of the card and one line between the Y and X punch rows at a rate of 100 cards per minute at 60 characters per line. The IBM 552's speed was 60 cards per minute.
I remember seeing a NCR computer around 1988 or 1989 still being operated with punch cards to do all the business and client accounting for a credit union, consumer store, industrial complex and agricultural coop marketing as one integrated entity. They had about half a dozen or so operators who exclusively made the punch cards with the transaction data. And they had three punch card readers, with a dedicated operator each, to load the data. Their whole COBOL program was essentially built by a single programmer. And for long term storage they used tape reels.
Ah a trip down my magnetic core memory lane. For Fortran col 6 was statement continuation character Columns 1-5: Typically used for statement labels. Column 6: The continuation indicator. Columns 7-72: Where the actual Fortran instructions are written. Columns 73-80: Usually ignored by the compiler and can be used for identification purposes like card sequence numbers.
I recall a computer by Univac had a panel of buttons with lights that the op would enter directly in binary for each addressed location in memory. A switch set the data into magnetic core memory that was built much like beadwork using copper thread. I also remember roles of punched paper tape 1" wide similar to what a reel of magnetic tape would look like, with punched code 8 bits wide. The Univac had memory modules as large as bricks, the CPU was larger than most household refrigerators, and the entire system took up the space of a full kitchen.
In my first programming course in college, I programmed a DEC PDP-8 in FORTRAN using Hollerith cards. Those where the days when was possible to accidentally drop a program (a sorted deck of cards) on the floor and scramble it. But that never happened to me, because I was a very good programmer.
One forgotten step in punchcards: in the mid 60s punchcards with outdated accounting data where used for playing around by a 3yo kid in the parents basement. That was the start of an IT career still about to last 5 more years till retirement. And more than 10y was on mainframes, that still today think they read punchcards. If you wonder, look at the JCL (job control language). BTW, most computers use ASCIi (or the superset Unicode). Most, but the ones that still run batches of (virtual) cards.
Fascinating video. I used a punch card machine for my Fortran class homework in college during the last '70s. I can speculate that you had a hard time finding documentation about how all this worked because it was a horrendous system. Like an abusive childhood, no one wants to remember it. Besides the horribly awkward, slow methodology of making the cards, it wasn't like you submitted this job and got to see the result in real time. The computer center would run it overnight, then put a printout of the results in the computer room the next day. The first time you submitted your job, it was almost certain there would be errors in the code that prevented it from running. I often had to do several rounds to get the program to run at all. And all this is before determining if the program was putting out the correct answer. It was awful. What we would now call a trivial program would take days to get the proper output. I don't know how computer programmers did their work back then. By the time I switched my career to being a software engineer, punch cards were blissfully residing in their grave. We can be grateful that they started the computer revolution, but even more grateful that they were supplanted by terminals where we could develop code on the screen.
Been there, done ALL that! Nice write-up of how bad it was back in the day. When I started writing code on a dumb terminal, dialed into CP/67 running on an IBM 360 mainframe using an 800-baud acoustic coupler modem, it was transformative not having to deal with card decks. And don't get me started about how futuristic those first IBM 3720-series full-screen terminals were when we got our hands on them. None of had any idea of what was to come as tech advanced faster and faster. I'm glad I witnessed the massive evolution in computing from a primitive stone age to where we are today.
We used to have a Sperry Univac 2200 system at UWC and to remember one day it needed a restart and they had boot it from a deck of cards … it was the IPL Inital Program Load sort of like the BIOS 1984 .. they still had a card reader in the computer lab
One of the reasons IBM was more successful than other firms is that they made their computers compatible with other machines. The character set is an example of this. EBCDIC (Extended Binary Coded Decimal Interchange Code) is an example of this. It was an extension of the character set used to transmit text on phone lines.
I was a Telecommunications Specialist with the United States Air Force in the 1970s. I worked in the Autodin system in England. It was the computer to computer digital switching center based com system of the time that was the precursor of the present day Internet. It was my job to troubleshoot com link outages and direct corrections. Each circuit outage required a slip to be filled out if an outage went over ten minutes. At the end of the day all slips were made into Hollerith cards for computer reading. The data on circuit outages were in that way collated and sent back to Andrews Air Force base in the United States for analysis and action. I was never good at typing these damned cards up correctly and had to do cards over again. 😀
Great video. One of the best overviews of technology history I've seen in a while. Fortran was my nightmare of choice back in the day. SOOOoooo much better now.
Even earlier than that, programs were like breadboard circuits, so programmers were literally setting the logic using wires, connecting contacts in the machine. A rack-like device with an array of holes was the frame, and wires with a plug on each end were used to connect the holes. Then the rack was slid into a holder which was swung down on an array of contacts. That is where the term 'bug' originated. An early programmer was Grace Hopper, who had wired up a program, which would not work, and when to find out why she lifted up the rack she found a moth stuck between a plug and a contact, and because Americans call such insects 'bugs', from then on whenever a program would not work they would look first for a bug.
We used punch cards in around 1979 on a single Apple II in my 6th grade computer class, but the type you can use a #2 pencil with. We did that because we only had 1 computer, but 5 students, so we could write our software on the cards. Then we would reserve time on the computer to load the programs with a card reader and debug our software.
I also remember learning COBOL in 1991 with those coding sheets. They were almost 14 inches wide by 11 inches high, with the coding grid pre-printed in orange ink. After writing our program with a plain pencil on the coding sheets, and getting the verification from our instructor, we would then transcribe that program with vi on a Unix terminal for subsequent compilation and execution in the same Unix terminal.
I used a Fortran compiler that could produce a “compressed punch card deck” with sequence numbers during the compilation. This gave me a backup of my Fortran program which could be sorted if I dropped it. The Fortran compiler could also compile from a compressed deck along with update cards when changes were needed. The “compressed deck” was analogous to “gzip” but for punch cards.
Dee, I appreciate very much watching your videos on computing. But you did a disservice to women's accomplishments in the history of all computing. You mentioned Charles Babbage being the person who invented (on-paper only) the steam-driven computing machine that is now called the Analytical Engine (later, he designed a better version, the Difference Engine). However, he was just an engineer, and he did not know much about algorithms, computing, or programming. Enter on-stage his best student: Ada Augusta King, aka Ada Lovelace. Ada (the daughter of Lord George Gordon Byron, the [in]famous poet) created the world's first programming language, based on Babbage's designs. Ada's notes included a sequence of program steps to calculate Bernoulli numbers, and how to adjust the settings on Babbage's machine to do such calculations. In other words, she wrote the first computer program designed for an interoperable, programmable computer.
I used punch cards in college in the early 80's, and at a job at McClellan AFB, where they had some super old computers. I don't remember now the model of the computer at McClellan, but I do remember they had to get rid of it when IBM said they would no longer maintain it, it was too old. I heard it went to the Smithsonian. I've used paper tape, computers with core memory, and drum memory. Fortunately, I didn't use any of those for too long, as terminals were just starting to be a thing.
Took a Fortran class in 1980; we had to use punch cards and card readers. By 1985, took a SPITBOL class and you could write all of the code on a terminal, which was much easier. That's assuming, of course, that a functioning terminal was available.
I've done a lot of punch card programming. Had the batch cards and then the data cards. Boxes. Then carry them to the mainframe building. An error, and a new card in its place. It worked.
I remember recycling the punch cards at a paper mill. They came in on a pallet in a pallet sized open top cardboard box. Good fiber. It recalled memories of being in the basement in Hughes Hall at Miami University turning in those cards for my Fortran course.
Yeah, I'm 60+ and I used that equipment - she doesn't look old enough. Programming tended to be different then for another reason - students had to know how to write their programs on paper, flowchart, desk check until they could punch. Now students don't even know Structured Programming before turning on their computer and typing into a Rapid Application Development tool where they find they have errors they can't figure out. Schools, in their effort to churn out graduates in minimal time, don't have courses explaining the basics of programming.
I started programming in 1970, on the IBM 1440 computer. The program source went to the keypuch department, which used the IBM punch card machines to enter the source onto the standard card decks. These cards were then fed into the computer's card reader as input for the language compiler program. (Assembler, RPG, Cobol Fortran or P/L1). The compiler converted the source into machine code, then sent the machine code to the computer's card punch. We had special plastic coated punch cards for the compiler output, because these cards got read so often. To run a program, such as order entry, we would get customer order header and detail cards from the keypunch department. You would take them to the card sorter, and sort them by fields like customer number and order number. These data cards would be placed behind the program cards for the order entry program, and then put into the computer's card reader. The loader cards at the beginning would tell the computer to read the program cards and load them into the computer's memory. At the end was a card that told the computer to start executing the program, and the data cards would be read and processed by the program logic.
I also wrote programs in university on coding sheets that then got converted to punch cards. Prior to that we wrote programs to paper tape.. what fun..
@@MrWibbleman I did paper tape too. Then the punchcards. After the paper tape, those punchcards felt like a giant leap forward. And then, the great miracle of typing APL on that IBM keyboard...
@@davidcassell4659 Ditto! Loved APL. Still can't believe though that we only had a workspace of 22k! 44K if you usd the backup space as a workspace. Never used the punch tape though... although the teacher showed us some. We went from Fortran with the large punch cards, to the small punch cards, to Basic then to APL on the terminal. If I wasn't in the darkroom, I was in the computer room. I can still recall dialing up the main computer on the phone, waiting for the modem tones, and plugging the phone into the coupler. Ah... the good ole days at 300 baud. 😂
I started university in 1977. Of course, no student was ever allowed to use one of the few terminals to access the IBM 360. We were taught FORTRAN, later ALGOL and SIMULA. After hours of punching cards we had to hand our box to one of the operaters who then loaded the cards into the card reader. That thing was fast, at least we had the impression. After some hours of waiting, we got back our box together with a printout on fanfold paper, only to find out that we had made silly typing mistakes and the job hadn't run because id didn't compile. Argh!
The main thing was to never drop your stack of program cards.
This eighteen-minute video takes 144,667,920 bytes of storage as an MP4 file. If we were to store that file on punch cards using only eight rows (one for each bit), it will take 1,808,349 punch cards. Since each card is 0.007 inches thick, the stack of cards will be 12,658.44 inches high, 1,054.87 feet tall, or 905 boxes of cards at 2,000 cards per box. A card reader reading at 600 cards per minute, will take 3,013.92 minutes or 50.23 hours to read 1,310,793 punch cards. 16,500 punch cards weigh 99 pounds, so this stack of 1,808,349 cards will be 10,850.09 pounds.
"using only eight rows (one for each bit)"
Which isn't actually realistic. This would require *lots* of holes to be punched in some cases. This was avoided, because doing so made the card structurally weak, making it more likely to jam the card reader. If you look at that decoding table Dee shows, you will notice that even though that type of card has 12 rows, which gives you a theoretical 4,096 possibilities per column, there are only 64 characters in the table. This allowed them to create a code that would keep the holes well spread out.
@@fllthdcrb I worked with punch cards in my early years, so I know too many holes makes a punchcard into a “lace card”. I’ve turned on the option for the mainframe to punch out an object deck and there were definitely more holes.
This is why terminals still default to 80 character columns.
But you’ll note that there are only 72 usable columns on the 80 character card. The other 8 are for special codes (known as Hollerith codes). 80 works quite well from a binary point of view (64 + 16) which may have been more of a factor.
I used to work for a company that had 80 columns as part of their coding standards, in the 2000s! I complained saying we're never gonna punch this out on cards! To no avail of course.
@wmrieker I had to write some cross platform C in the mid 2000s for a bank. It had to be able to run on IBM mainframes among others, which meant the code was constrained to 72 character lines and had to work with EBCDIC as well as ASCII. It still hangs about today.
@@stevetodd7383 In 2021, it emerged that a Belgian bank was still using EBCDIC. A customer complained after the bank omitted the umlaut in his surname, citing GDPR’s right to correct inaccurate data. The bank argued its EBCDIC system couldn’t handle diacritics or lowercase letters, but the appeals court sided with the customer.
@@stevetodd7383 I first used punch cards in 1972 in college for my FORTRAN class. All 80 columns of the punch card were physically equally usable in the keypunch machines and the card readers. All 80 columns used the same Hollerith codes. As seen at 11:31, by convention, columns 73-76 optionally contained a project label, and columns 77-79 optionally contained a sequence number in decimal. Typically, column 80 contained a blank or zero, but it could have a digit if you wanted to edit the card deck by inserting a card and still have the numbers in sequence. In case the card deck was dropped, in theory the sequence numbers could be used to restore the cards to the correct sequence manually or by using a card sorting machine.
My first job in flight simulation was working on and programming simulators from the mid 1960’s. They used a DDP-124 computer, 24 bits 32k RAM.
We had all the original punch cards that came with the simulators and still used them to update the radio database, until I found an easier way.
After we made any software changes we would create a new load on paper tape. Paper tape was faster to read and if you dropped the spool all you had to do was rewind, not sort. Eventually we modified the computers to use an IBM computer to load the program directly into memory using the DMA bus, so paper tape was only used to create software changes.
A skilled programmer could read the paper tape and correct any errors that the 30 year old puncher created.
I am enjoying this trip down memory lane.
This is such a underrated channel, crazy.
This gets me to understand Batch programming better by seeing it started
If you notice at 11:10, there is a diagonal marker line across all the cards. This helped with re-sorting in the unfortunate event that the stack of cards got dropped. It's a quick way to initially re-sort the cards.
This is why explicitly numbering lines in BASIC was such a brilliant idea at the time. I don't know if the original compiler could ingest code out of order, or if it was just for programmers' benefit, though.
You may have noticed on the far left side of these cards, there are a numbers of cols unused in this example. Those were for sequence numbers. COBOL in particular used cols 1-6 to store the sequence number which will also get keyed by the keypunch operator. Then if the deck of cards containing your source program was dropped, you could feed the unsorted deck thru a machine called a collator to get the source deck back into order. That in and of itself was a time consuming process, and you could do a video on how the collator worked. Suffice it to say, it provided for getting an out of order deck back into order. Love these videos!
@@mdn8rdr5903Also in columns 73-80. The earliest computers for which FORTRAN was designed had readers that could only read 72 columns, so the last 8 were reserved for sequence numbers. That way, if they were dropped, a few passes through the card sorter would put them back in order.
This was such a good idea that even for computers that could read all 80 columns, language designers started to reserve the last 8 columns for sequence numbers.
There were sorting machines that could read a column and put the card in that numbered bin, you then collected the bins into a single stack. By repeated sorting on columns you could sort a deck of cards with this.
@@mdn8rdr5903 Thanks for the info, I was wondering if they didn't already thought of a machine to sort the cards, in case of accidental mix-up, because just making a diagonal line by hand with a marker, seemed like a very error prone system to me.
And if you can make a complex card reader, you can certainly make a card sorter as well.
When I got my computer science degree I used cards. Dropping your cards stacks with ALC (360 Assembler language) was an amazing problem. Built using ALC 360, Fortran, RPG and Cobol. In Cotton processing, cards were used to track cotton bales for managing gin cards and compress cards and the USDA issue classification cards. The cards represented ownership. After the 80 column cards, we used 96 column cards, which are smaller.
Later I worked for IBM for 30 years.
Yea... that was surely one way to ruin your day. Fortunately when I was doing Fortran in school I never dropped a stack... can't say others in the class were as fortunate. 🤭We started with the 80 column cards and switched about 1/2 way through the semester to the 96 col cards. I don't ever recall seeing the small cards in use out of class... where the large cards would pop here and there for billings in the mail, etc for several more years. I don't think the small cards were ever widly used much and not for for very long.
When I was going to a 2yr tech college, a fellow student found out the hard way why it was a good idea to punch sequence numbers into the cards! Ahh yes, the 96 column cards the System 3 used, along with RPG!
@@douglascaskey7302 the NY state through way used them into the 2000s to know where you got on as you were exiting.
One trick is to draw a diagonal line with marker pen across the edge of the card stack. It makes it far easier to sort if you drop them.
I learned basic programming language at collage in the early seventies. I wrote the program on a piece of paper which I gave to a gui who punched the code onto a paper strip. The paper strip was used to send signals over the phone to a central computer somewhere. 4 days later I would get a printed paper back with a lot of question marks and gibberish. To me the zx spectrum was a revolution. With instant feedback i could have some fun programming.
I have done it all. As a prototype tester I keyed small binary programs in the computer main memory and afterwards I punched it on paper tape to reuse it (1970/71). When I changed to OS programming I used punch cards (1972) for a short period, then the ASR 33 Teletype (1973) and a 24x80 CRT display (after mid 1973). I used assembler for IBM 360, PDP 11, P800 Philips mini computer (1980) and P1000 Philips main frame (1970). From the programming languages I used mainly PL/1 and RTL/2 (a UK language comparable to C), but I learned Fortran, Cobol, SQL, C and Clipper. SQL, C and Clipper I used occasionally.
I stopped programming around 1985, because I made a career as chief architect and department manager.
I used Hollerith punchcards when I was a student at Georgia Tech. I learned read the holes. I used that ability to astound my fellow students. The first card in a card deck included the user's name and password. You were supposed to put a blank "cover card" to hide the first card, which usually had the text along the top with the user's info. Often, students would skip the cover card and black out the text (or if they were savvy, they'd turn the print function off on the key punch). I would chastise others, about the missing cover card, rebuke their protests, and announce their username and password, to their amazement. This was made easier since a great many students used GATECH as their password.
I wrote my first AI program 50 years ago on an IBM 360 in Fortran using punch cards. Thanks for the look back. Love your videos.
That's cool as hell. What was its function and how did it work?
I started my coding career in the 1970s. Card punches were everywhere, and I got very good at using them. Then came a day when I used a card punch machine for the last time, and I felt... the same as any day because I had no idea it was the last time, just as with so many "last times" as you live your life...
The last time you rented a VHS at a video store. The last time as a child that the whole gang played together. The last time you mowed a neighbor's lawn to earn some cash. The last time you played a physical CD in a car. The last time your child asked to be lifted up and carried. There must be many more that I don't have time to write down, right now. BTW, this post was inspired by something I read recently, but I can't remember the source. It was a good read that I wish I could find again.
I was a programmer in the 1970s and I've punched a lot of cards. Dropping the card deck was a bad day. I had so much practice that could read most cards by eye - which was handy when the "human text" was missing. There was also an End Job card as last card - if you forgot that the machine would read your entire deck then reject it and move on to the next job. Also there was no "backspace" on a punch machine - one slip and you would have to bin that card - and if you forgot to remove it, it would end up in your deck, which would then fail. Thanks for an excellect overview of this long forgotten tech.
I remember editing programs on punch cards. You would duplicate the line with the card punch machine, then type the correction which would replace the characters. You could insert characters by holding the left card (card being read) and typing. You could delete characters by holding the right card and pressing space to advance the left card. It was also cool to make cards where the holes represented letters (think dot matrix)
I remember sticking the chads back in the holes for a quick edit. Not recommended!
Fun fact: there are more (a *lot* more) ways to punch a single punch card (2^960) than there are atoms in the entire (observable) universe (~10^82). I still can't quite wrap my head around this!
if that was to save a variable, wold that type be the mother of all floats ?
Punch cards were used to enter keying material into old Kw-26 crypto machines in the past. We used decks of them to get crypto sync up with distance communications circuits in the Air Force in the 1970s. Decks were kept in crypto vaults in the crypto room behind cyber-locked doors. The decks were transferred to end stations under guard at that time.
one card was one 80-character LINE in program
and it was useful to manually write number on each card, to maintain order in deck, if you accidentally drop it on floor
@@davidsault9698Precursor to SSL?
You seem to be referring to the number of possible combinations of holes punched/unpunched in one of those 12×80 cards. But please note: the vast majority of those combinations would be unusable, because punching too many holes structurally weakens the card, which can cause it to jam the card reader. That's why, despite each column having 4,096 possible values, you will note the table we see in the video only has 64 entries.
This is why 80 column displays were the norm on early PCs and terminals, and is still typical on IBM 3270 format displays to this day.
We think that we are the smartest developers in history, but developers in those early years were the real heroes
Some of us think we still are 😉 😂
@FredBakker, thanks. I never thought of myself as a hero. I just felt like a good assembly program coder. -toby
I was THERE. Using punch card machines to program FORTRAN. Nothing like waiting in line to use the 4 punch card machines in the computer room. We had programs that were a quarter box of cards, a half box of cards and a full box of cards (or even multiple boxes). I believe it was about 2,000 cards to a full box (they are 0.007 inches thick). After the cards had been read into the card reader a number of times, they started to get worn and you would add a command to your input to duplicate your deck using new cards. I programmed on a Control Data Corporation computer running first the SCOPE operating system and then the NOS/VE operating system.
I started programming Fortran on a CDC computeur in 1966. Frustrating that, when you start programming, you put your cards in the box to be processed and you would get the results in the morning: syntax error! This was at Polytechnique Montréal, school of engineers.
@@pierreforget3357 I started at AiResearch in Phoenix in the spring of 1977. Before the company had its own computer, the engineers before my time (late '50s or early '60s) DROVE their card decks 5 miles to Arizona State University to be run!
Were there any tools to help find bugs? Or was it a case of knowing it was a recent card and going through the last 100 or so?
@@mattevans3511 One of the more experienced programmers taught me how to decipher a core dump. Pretty primitive stuff. As I recall, you could figure out the line of code where it crashed and then work your way through the various operations on the line to figure out just which one caused the crash. Visual debuggers (which came MUCH later) were such a boon.
@@mattevans3511 Yeah... a big printout of the green / white line tractor feed paper with the prgram, data & memory dump. Then you have to pour through the stack of paper trying to find the bug. Thing with programming with cards is a bug could be something unrelated to logic. Could have been a typo where there are no spellcheckers or compilers to flag errors or it could have been forgetting to put a control card in the stack. It could also be tedius punching the cards... if you made a typo you'd have to trash the card and repunch. I was actually glad (at schoool) when we switched to learning APL on the IBM terminal. No more punch cards. Yay. Although that in itself baffles one's mind today... we had a workspace of only 22K!... 44K if you chose to use the backup space as additional workspace.
02:42 suddenly, Pesto got into the video, sure this pinguin is going to places, BTW: Pesto is molting now, into his black and white fur.
This is probably this is folklore: at IBM somebody was explaining a punch card, when an IBM engineer walked by, joining the lecture, grabbing a piece of paper and a pencil, using the pencil to punch a hole on the paper: Ladies and gentlemen, this is a punch card.
I was thinkin about music, and those old pianos with a rolling piece of paper with holes playing music; they did not make your history.
Great content Dee, I love it, keep producing them, cheers.
Brings back memories of my first trip through college. Took Fortran IV using punch cards. My biggest take away was to make sure the deck had a !EOD card.... If not, your cards and green bar paper would be no where to to be found. Asking Bob the computer guy for them was not advised since the computer would have to be unplugged and Fortran had to be reloaded.
X and Y not marked because everyone knew exactly what they were; 0-9 a little trickier. Most cards that I worked with were entirely unmarked: We just trusted the key punch operators. Besides, the top-line was usually legible. First thing you did with your deck was just printed out on green-bar (133 column x 58 line alternating dark and light green paper) so you desk-check it and resubmit correction. Late 1970s we graduated to terminal entry.
Not X and y. The top rows were 12 and 11.
@@guymarentette2317 A hole in the 11th row over a numbered hole meant the number is negative. The hole in row 11 was called an X punch.
Row X and Y were unmarked to allow printing of the characters on the card using an IBM 557 Alphabetic Interpreter or IBM 552 Alphabetic Interpreter. The IBM 557 translated holes punched in cards and printed the corresponding alphabetic, numerical, and special character data on the face on two lines: one line across the top of the card and one line between the Y and X punch rows at a rate of 100 cards per minute at 60 characters per line. The IBM 552's speed was 60 cards per minute.
EBCDIC - Extended Binary Coded Decimal Interchange Code (later on microcomputer replaced with ASCII - American Standard Code for Information Interchange used where characters were represented for English and European based languages). With the rise of the Internet, it became necessary to represent languages that were phonically or symbolically displayed. Unicode allows for most of the worlds languages to be represented.
Yep, the fun part was moving EBCDIC formatted data to ASCII. Programs would fail as the two systems had different sorting sequences, you would get data errors. I had seen this before and fixed it when replatforming an application from an IBM mainframe to an HP system. Years later I managed a team who were doing something similar and we ran into the same problem. I gave the team one day to figure it out. In the end I had to tell them how to fix it. Fun days.
„replaced“ is a bit misleading. It is still used on mainframes (360 inspired ones /360,/370,/390,/z,…) and it only feels like replace, because all the „smaller“ systems (unix-like) just have expanded so much.
IBM would for sure severe issues if they would replace EBCDIC with ASCII in their mainframe operating systems. And they are still the ones starting a partition running one of the hundreds Linux instances, that share one heavy box.
@@philiparonson8315 you sir have a strange definition of fun.
Oh, my God! I've been into programming for over 3 decades and surely have heard about punched cards. This video however first time I ever got to learn how it's applied to program computers in the past. Thank you so much. I will also checkup the link in the video description.
Columns 1-5 are for a statement number. Fortran before f77 version required the use of go to statements so if you wanted to branch to a statement it had to be numbered. Column 6 is a continuation flag. Anything punched there except a zero indicated the statement was a continuation of the previous statement. Columns 7-72 is where the code statement goes. The remaining columns were optional card numbers. If you filled in card numbers and dropped your deck you could take them to the sorting machine and recover.
Fascinating history! Amazing to see how far back the influences on computer programming goes!
This is how I learned Fortran in 1979. You did not want to drop your cards! Many of us ended up numbering the damn things.
Oh yeah. I had a retired Army programmer teacher (read: former electrical engineer) who told me his old office staff included a person whose job was only keeping track of those cards, numbering and inventorying them, maintaining their quality, and so on.
One quick method was to use a black marker to mark some design, or even just a diagonal line, on the edge of the deck. Reconstitute the line, and you've got the cards in order.
@@justliberty4072 This is before my time, so I never experienced this personally, but that diagonal line system, seems to me like a potentially error prone system, is better than nothing yes but in my mind, depending on the thickness of the deck and the angle of the diagonal line, it would be very easy to mix up two very similar lines, created next to each other, as they could only differ by a millimeter or less.
IMO numbering them would be a way better system and based on other comments, a machine existed to sort them, by using info punched in the cards itself, but this last one was probably only used by companies, not individuals, as that machine was probably not cheap either.
If you had access to a card sorter you could punch the card numbers in the last few columns of the card before dropping them. Then feed the scrambled cards through the sorter a few times to get them all back in order.
@dale116dot7 in college? Not a chance!
After my dad got retired from the Army in 1986 he went back to college to get a degree in business management and one of the classes he had to take was a computer programming class in COBOL. I helped him with the class and they were using punchcards and batch processing for their programs and I was surprised that is 1987 they were using punch cards.
To be technically correct, the Assembly Language is a low-level language, as this is just a symbolic notation of a machine code. It does not require a compiler, and it is absolutely hardware-dependent. Thus it is very different from Cobol or Fortran, which are high-level programming languages.
To be technically correct, Assembly language IS machine code.
As you state it is just one of many ways of encoding the patterns of electric voltages recognised by the computer as representing individual instructions. Binary, octal, decimal, hexadecimal, assembler mnemonics, True&False, High&Low, or any other method of storing an individual machine instruction as an arbitrarily agreed group of symbols. An assembler is simply a symbol translator.
Admittedly an assembler can include functionality to make life easier for the programmer such as replacing mathematical expressions or label references with the resulting values but that is no different to the programmer using a calculator, look up table or manually calculating the result themselves. In the end an assembler does nothing but translate the source code into individual instructions, specifically selected by the programmer for that particular processor.
High level languages (compiled or interpreted) however, produce 'groups' of instructions, chosen by the translating program based on its understanding of the programming structures used by the programmer and its own previously selected usage of processor resources such as registers and memory allocation.
All compliant assemblers for a given processor will produce exactly the same set of instructions given the same source code (assuming it doesn't contain any non-standard assembler directives) whereas it will be VERY unlikely for a compiler to produce the same output for any non-trivial code, even if the resulting machine instructions do produce the same overall result using an alternative method.
@@MikePerigo
Yes, Assembler is just the machine code, but especially on mainframes, they have macro-assemblers, that are allowing you to define your own language within.
Their features are way beyond what a PC macro-assembler would provide.
@@fromgermany271 Macros are just pre-written assembly code snippets written or selected by the programmer. Admittedly professional assemblers have more bells and whistle features than basic offerings, such as conditional assembly and lexical replacement facilities but any assembler only produces output containing the exact instructions chosen by the programmer.
Any code generator that automatically produces code containing instructions not explicitly specified by the programmer, variable allocation, memory management, bounds checking etc. is no longer an assembler but a compiler or interpreter. Even low level languages like APL or PL/1 allocate memory based on internal rules rather than the programmer having to make those decisions.
@@MikePerigook you are hurting me. No assembly language is machine code, all of them went, and still do, go through an assembler to generate the machine code. In almost all cases if you were programming in direct machine code, if you were lucky you had switches, if not, get out the wire warping tool. I did all three, and as I learned not all that long ago, I still remember the bootstrap switch sequence for an LSI-11 (as the tech on the other end of the phone was reading me the settings I realized I had already rebooted the electron microscope by finger memory). I’m sure I’m not the only one here who could do similar on any PDP, IBM, UNIVAC and others.
@@jlholmes8 I don't disagree with that. I agree that true machine code is a sequence of electrical signals that the processor acts on. The point is that in order to generate those signals the desired instructions have to be encoded in some form and stored in the memory. The input method and choice of symbolic representation are immaterial. Whether you use switches, lasers or plain old copper wire to transfer the instructions chosen by the programmer and eventually stored in memory they have a one to one relationship. An assembler is just one of many encoding schemes that can be used. Unlike languages that generate code in line with a programmers desires an assembler literally just translates an encoding method on a one for one basis.
First, I learned typewriting when I was 12 years old in 1965. Then my typewriting skill enabled me to learn card punching in 1972. I worked on the IBM 026 Card Punch machine and the IBM 024 Card Verifier. I was able to make program cards for operator use. Then, I foolishly left my first job to take another job as recommended by an employment agency counselor. At the second job, I used the IBM 029 Card Punch machine and the IBM 059 Card Verifier. Also, I gained exposure to the Entrex Data Scope, a data terminal with a keypunch-like keyboard. In 1979, I worked on the IBM 3742 Dual Data Station and occasionally on the IBM 3741. I began to lose some flair doing keypunch, because data from the source documents were predominately numeric and nil to no alphabets. I feel satisfied that the microcomputer with the 104-key keyboard changed the way business documents would be made. Your show impressed me very much.❤
24 was a keypunch, the 26 was a printing keypunch, the verifier was a 56. 29 and 59 came out later.
One thing is that early monitor displays had 80 columns x 25 lines. This was to accomodate 80 characters from the punch cards and the cards were grouped in 12 cards, making two sets for 24 lines and one extra line to input commands. When the first IBM PC DOS marchines were produced they kept this format, that endure up to Windows XP, later in Windows Vista it became 80 x 50. Later versions got rid of the 80 columns limit.
There was excellent documentation on all aspects of Holerith cards. The way they were read was standardized, but not always used. Since the cards were used for tabulation initially, the encoding you mentioned isn't always used.
My favorite use was to vote. In California we used Porta punch devices to knock at one hole at a time to vote. Each hole represented a choice. A card reader simply counted up how many of each hole was punched. To prevent overvoting, when the card was read, if 2 votes for the same office was punched, a program would treat it according to local law. At large corporations we rarely punched our own cards and sent forms for professional key punchers to punch. Once we got IBM 3270 with TSO we did most programming on screen.
The top three rows on a Hollerith card are for the zone indicators used for entering alphabetic information, usually referred to as 12, 11 and 0 rows. Row 12 plus a numeric 1-9 encoded A-I, Row 11 plus 1-9 encoded J-R, Row 0 plus 1-9 encoded /-Z. Numeric data was encoded with rows 0-9 punched without a zone punch (except in a numeric field an 11 punch in the units position indicated a negative number). Special characters were encoded with the addition of an 8 punch in addition to some of the alpha characters.
My first couple of Comp Sci courses we used punch cards to program in IBM 360 Assembler and PL1, this was 1984 at the U. of SC.
I learned both languages in the late 70s. The punch cards were gone from my life by the mid-80s. I stopped coding in IBM assembler in the 90s, but still used PL/1 until I retired in 2015. A great language, that PL/1.
It was so painful having to type those cards out. You would make a mistake and have to eject the card and start over. Then they came out with punch machines with a display that allowed you to make corrections as you type and only when you were satisfied with the line did you push a button to have the entire card punched. As a teenager I got a kick out of listening to the sound, especially when some machines were still the punch as you go vs the new ones with displays. You would heard punch, punch, punch (at a slow typewriter speed, trying to avoid mistakes at all cost) from half the room and the other half was like listening to a machine gun firing. LOL
That machine was the IBM 129 Card Data Recorder. It stored 80 characters in memory as you typed the characters before punching the card.
Another good video, Dee. Fun fact there was a punched card system still in use in the UK right up until the 2010s! Punched cards started to be phased out as higher level programming languages came to be created in the 1950s and 1960s. Another name you will be interested in is Kathleen Booth, who invented assembly language in the 1950s. She also wrote one of the earliest programming books for assembly programming.
I started programming in 1974 in assembly. Thanks for the trip down memory lane.
Misery was feeding your big deck into the card reader and then hearing a sickening crunch as a card got jammed and shredded inside the machine. Usually caused by cards that were bent or misshapen by being read too many times. At that point you had to determine which card got mangled and re-key it and try again.
definitly...😦 ..my sorry to hear that 🥴
from fabric machines to super computers to where ever it takes us now is sooo amazin...i only wish i could be here 100yrs from now.
my fist programing was on a terminal in Charleston SC while I was learning Fortran 4 in 1976. It was using the "Punch Cards" and the assigned program was to Solve a Quadratic Equation. Of Course, one of the Feared outcome of running the program was that the output was on a printer and have it in a infinite loop. If always amazed me that my program was about 30 punch cards and the Cabal programmers' cards were 100 or more. Then when I started programming in DBase3, I learned that Database programs are much longer because of the size of matrix of Columns (Fields) and Rows (Records). I also took a course of Assembly for the 8080/8085 microprocessor in 1984. I saw my first CNC type machine in 1967 while working in a Manufacturing Plant as a Lathe Operator. The, I never used it or saw it run, CNC machine was a small Mill and was run using IBM Punch Cards, Programed by Engineers. This type of history is base level, like the Loom you started with.
Dee this is great. I remember my father working with punch cards and I had always wondered how they work. This is the best explanation I've seen/heard/read. Thank you!
Hey Dee, wow, you are such a great communicator. Your obvious technology background, easygoing manner, body language, and speech patterns, make for such interesting listening. I like your use of graphics ( and introducing your dog!) . Please keep up the great work as you as a special person who has found their niche. Bruce from Australia
The keypunch machines had several cool features. The card you just finished moved to the left where it was being read by the machine. Sometimes you could press a certain key on the keyboard and the card you were working on would copy the character of the prior card. There was also a rotating drum up and to the left; you could open the door, remove the drum, put a card onto the drum, and the holes in the card you put on the drum would instruct the machine to for example skip the first 6 columns and start in row 7 (handy for Fortran at the time), or when you get to column 10 copy columns 10 through 20 then eject the card. Most didn't know how to use the drum cards, but knowing that did save quite a bit of time depending on how repetitive your cards were. Another invaluable machine was one where you fed in your deck and it would print out what was on the cards. Great for debugging and making sure your cards were in order. Some key punch machines did print the line of code at the top of the card; but some didn't.
In 1975 on the IBM 360 in college you also needed a Job Control Card which was sharp corner rectangular. It told the Reader/Computer that a new job was being run. That way the billing for the computer time use could be applied to the correct account. Fortran programs were often only run in batches when enough jobs were waiting for them to load Fortran into the computer. When I had a typo in the card deck and had to retype the card and rerun my program it could take a day. I tried to shorten it by having a small deck of Job Control Cards to have a dozen or more jobs that basically started then stopped doing nothing in between. That would increase the count to get the batch to run sooner. Then the computer crashed for half a day twice. When I came back in to run again, they said "You're the guy!" Apparently since most jobs were by researchers with decks a few feet thick, the accounting was done in the background. But IBM discovered my trick provided a new job faster than it could bill the old one, causing those crashes. They modified the handling of all jobs to add a small delay to allow for the accounting before proceeding with reading the next job. Thankfully because I had not caused the crashes on purpose, they didn't kick me out off the computer.
The code also doesn't use all 12-bit space available, instead preferring codes with fewer holes, especially not adjacent holes. And I just now realized that putting spaces between tokens improves the integrity of punch cards.
4:40 The correct transliteration is Semyon. The accent is on the second syllable
I took Fortran programming in 1977 at the University of Alabama in Huntsville. We used punch cards. It ran on a Univac 1100/60. The University made LOTS of money allowing time sharing on this main frame computer by allowing the local defense contractors to run programs on it. A BIG program, carried around in boxes was about 1500 lines of code. It was about this time that the keypunch machines were upgraded to NUMBER the cards. That way if someone dropped a deck of cards, a sorter could be used to reorder the cards. Another Huntsville first was it was home to one of the very first COMPUTERLANDs. They sold kit computers that you had to assemble yourself AND they sold programs on paper tape. I replaced a MUSEUM quality teletype terminal with an HP-85 in about 1984? at the hospital that was running a piece of medical diagnostic equipment. Things have come a long way in a very short period of time.
I enjoy and appreciate your channel. Thank you.
My, recently concluded, 45 year IT career started in 1979 as a computer operator on ICL 2900 series hardware, my first 2 programming languages were COBOL & ICL PLAN Assembler both learnt, by trial-n-error, on the midnight shift as an operator with all my programs written on punch card (courtesy of an IBM 29 Punch machine) I finally junked the cards in 1996 when I moved to Denver Colorado. Given my typing skils, I have to say, I dont miss them! Afterthought! I just recalled something I learned back in 1979; the punch card is the most inefficient form of data storage ever invented. This is because all the data is stored in the holes, the card is only there to hold the holes in place. The card is therefore 100% redundent and carries no information.
The blank column is dependent on the programming language, but can represent that the data typed on the line is not to be executed (a comment) OR that the line is or will be a continuation from another line. Continuation in FORTRAN would be rare (and likely not a good idea), however lines in COBOL could get quite lengthy and continuation might very well be necessary.
Back in 1977 I wrote my first program using Punch Cards on a DEC PDP11/04 while in High School. We also created Student Records on Punch Cards. Each punch card contained several fields of data which were controlled by a coded punch card that wrapped around a drum inside the the key punch machine. Keypunch machines were no joy to type on. To get the cards in a specific order had to be run through a massive sorting machine with a bunch of cables connected to hubs in the machine to determine how they were to be sorted. Its been a long time just the way I remember Alpha Numeric Data was by remembering J and R. Numbers were simple just one punch on the line to get 0-9. Letters were required 2 punches per line one at the top of the card and then a punch on 0-9 to get the letter. There three lines at the top one line and a number would represents letters A-I the next line would represent the letters J-R and the last line for S-Z . That's all I recall about the 80 Column Punch Card. Then we got to play with 80 Column Mark Sense Cards using a #2 Pencil to create the marks which replaced the holes. I never got to play with the 120 Column Cards but as more of that PD11/04 became functional we got to play a CRT Terminal which was a money saver because Hard Copy Terminals just wasted paper.
Thanks for your great work!
However, I just want to point out one more thing.
A program consists of algorithms and data structures-in your words from the Apollo computer film, instructions ("verbs") and data ("nouns"). Initially, machine instructions (like on Jacquard’s loom) were "embedded" within the machine’s structure, while input data-like which threads to shift-were provided via punched cards. The output data was processed directly into analog output signals. Similarly, in music boxes, music was "encoded" onto a cylinder, and the code was "hardware-translated" into sound.
The same goes for the telegraph and teletype, where data was recorded on paper tape for later transmission or reading to streamline the process. The 'instructions' controlling the operation were 'embedded' in the construction of the machines.
Maybe it would be worth making a video about the history of perforated tape and teletype?
The first applications of cards and tape were for data storage. A true breakthrough happened when Charles Babbage and Alan Turing suggested that program instructions should also be treated as data for the machine, allowing not just data but also instructions to be recorded on cards or tapes.
@boguslawszostak, it has been suggested elsewhere, that the earliest programming algorithms were instructions on how to knit a garment. Knitting instructions can include subroutines and functions with replaceable arguments, conditional loops, and all the basic ideas we can find in early programming languages. -toby
@@tobyr21 There has been a misunderstanding. The key point is that the earliest weaving machines didn’t really have "instructions" as part of their programs; instead, the "program" consisted solely of an encoded "pattern," which is to say, data. The way they operated was entirely determined by their physical design. This is easier to illustrate with a barrel organ. On the drum, there are holes, and the whole mechanism is only capable of triggering a sound "through hardware" when a hole appears on the drum. The machine can only convert the sequence of holes, in a fixed order, into a movement that produces sound. Therefore, there are no "instructions" explicitly written anywhere; they are embedded in the machine’s design.
In Jacquard looms, the holes merely conveyed the positions where the loom’s components should be set according to the specified pattern.. The true breakthrough was the realization that instructions-what the machine should do, rather than just the data it operates on-could themselves be treated as data.
@@boguslawszostak1784 I'm not disagreeing with you. I'm just pointing out that knitting instructions can be, and were, even in the 19th century, complex algorithms with the essence of what we recognize as programming. -toby
I started with punched cards in 1975 on an ICL 1903a running George 2+. Sometimes we would use a hand punch machine. The other method was paper tape. The old definition for Turnaround time was the time between submitting your cards and receiving the remains. At least coding changes where replace a card. I do remember my dad taking me to NatWest Bank’s computer centre in London and setting me up to run one of the first IBM 360s in the country to do tests using punched cards to tape whilst he and his colleagues fixed some tape drives.
Calculators, tabulators, etc were programed with "program boards" that were essentially patch boards using jumper wires to "process" the data on punched cards prior to the GP computers. Yes, I'm old enough to have seen them at work. SAFETY TIP: Do not wear neckties tied around your neck, only clip-ons. Unit record devices WILL confuse the end of the tie for a card long enough to cause, at a minimum, a Workers' Compensation case.
Another thing that's pretty funny here is that dropping a deck of cards was pretty rare, and usually harmless because of advanced rubber band and cardboard box technologies. 😉 You were much, much more likely to screw up unnumbered cards while trying to edit. For example, refactoring duplicated code into a subroutine typically required either a large workbench or using a bedspread as a makeshift workspace. Unfortunately, few programmers had cardpunches inside their bedrooms, so whatever large surface nearby the "computer room" would be used. I remember a colleague explaining he'd use a gymnasium floor, but once had his work destroyed by editing too close to a door on a windy day opened by surprise. A few CRTs were available for editing long before punchcards stopped being the mode of initial program coding.
@@jsalsman tripping on the stairs with two made me really glad only two rubber bands broke. I think each were 50. Sequence numbers saved more than just me.
Ms Dee, until I just watched this, I had never heard of “punch card programing”. As a nit pick, Hollerith cards were/are (yes the are still in use) not paper but a very thin sheet of cardboard (my uncle made them for IBM, who then resold them to everyone. He saved me a lot of computer funds in college) or later vellum like “paper” tape (also still in use by a not-so-small international in midtown Manhattan).
I never realized though the loom was the first punch driven (I can’t say programed) device, I had always thought the player piano was.
Thinking about the loom though, while not cards but paper tape, high speed band printers used basically the same technology. It does make sense as I now think about it. I wish I knew it in the 90s when my assistant/operator would ask me every month at billing time “who came up with it’s , it breaks every two hours!! I don’t think I ever told her how often grade statements ripped apart the ribbon and trashed the band at the same time.
Sort of high speed laser printers (five for the price of a one year maintenance contract) paid for themselves just on the overtime every month.
Someday I should write the 70s through 2000 memoirs of real-life computing.
Thanks for bringing up memories of my youth! In early FORTRAN versions, the statement started in column seven and ended at column 72. Columns 1-5 were for statement numbers - labels for GOTO's. If any character was in column 6, the card was interpreted as a continuation of the previous card. Columns 72-80 were for identification - you could number them to help out in the case of dropping the deck on the floor (not that it ever happened to me ;-). It was painful to make these cards as one mistyped character would make the card useless. I wonder how many of the 10 million cards per day created were later used to make Christmas wreaths.
There was another form of programming for punched cards that was used on card processing machines such as IBM 407's (tabulator) and IBM 82's (sorter). These were programed by hand wiring boards that were plugged into the machine which changed the circuitry of the machine. The 82 series of machines could sort on any combination of columns and the 400 series of machines could interpret the data on the cards and print reports such as tabulating columns.
That's very interesting. When I first found out about punch cards I wondered how they worked. Great explanation!
Fun fact: When I learned COBOL in college in the early 90's if you had to write a statement in multiple lines, the second line had to start 4 spaces in (B section). The reason is that in the days when the dinosaurs roamed the earth and you wrote your code on punched cards, the way the parser understood that the statement continued in other cards was with this indentation and that was kept even when you wrote code on a text editor
Like many commenting here my career started in this way. Our coding sheets were sent off site for punching (actually in a different town). It was typically 2 weeks until you were able to test your code when the cards returned. An instructor at the company I worked at , supposedly coded a program with 2 statements per line, using a GOTO as the second statement on every card. As the story goes if the card stack was dropped by an operator, only the first and last card needed to be correctly placed for it to work correctly!
row 6(?) is used to indicate that this card is an appendix to a previous card. this enables program lines with more than 72 characters. i hope i remember this correctly. i used it last time in 1985. The first seemling unused rows are meant to contain Format-instructions for inputs and output commands. Thank you very much for this video, love it
I started programming with punch cards in 1966 on an IBM 1620, first with machine language, then with assembler (SPS on the 1620), and then FORTRAN II. I later moved to the university's IBM 360, and later after a stint in the Army to an ITEL AS/370 (NOT Intel), a clone of an IBM/370, all with IBM FORTRAN IV G and H. For my graduate research I read some of the data I needed from Sandia Laboratory microfiche reports to punch them onto approximately 4000 cards, then had to check every card to make sure the data had been transcribed correctly. After beginning work at Oak Ridge National Laboratory in December 1978, I continued using punch cards there until sometime in the late 1980s when we finally began using personal computers as terminals to connect to our mainframes or Unix workstations.
The best punch card story I know I heard from a complete stranger in a Mexican restaurant in Las Vegas in February 2008. I was waiting in line to grab a bite after visiting my wife in the hospital. Strange as it sounds, somehow the conversation with the woman ahead of me turned to old computing and punch cards. It turned out that both she and her husband were in the Army during the Vietnam war with her having an assignment stateside and her husband was in Vietnam. Both were in administrative units handling logistics and had cause to transfer logistical data back and forth between their units using punch cards. So they starting writing each other lettters using punch cards but turned off the printing on the keypunch so no one else would figure out what was going on. When one received a box of cards from the other, the recipient would run the blank cards through a card duplicating punch, but with the printing turned on so they could see what had been written. I thought it was quite clever.
When it came to getting data into early computers, punched cards had a similarly low-tech competitor: punched paper tape. Borrowed from use with teletypes, you had a long strip of paper with holes punched into it to encode characters as used by the teletype systems of the day. Many early computers had instruction sets that were designed to be easily encoded on a teletype, and word sizes that were multiples of the 5-bit teletype character size. Australia's CSIRAC being one such example, using 20-bit words.
Wonderful, I learned on punch cards. Do more history videos, they are grest!
When I was in college, there was a desk sized card punch machine in the corner of the room where we went to pick up our print jobs.
Students used to sit on it while waiting for their jobs to finish.
One of the grad students told me that it hadn’t been used in a years, but they couldn’t remove it because it wouldn’t fit through the door after some remodeling of the area.
I can’t even begin to imagine how to debug your punched card software. We have the same LEGO. Good taste.
When I was young, we sent off our punch card deck in Fortran or Cobol to be processed on an ICL mainframe, You had better not have forgotten the George 4 Job Card!
We didn't even have modern punches, you had to know the rows in each column to punch for each character and press the right combination of keys.
I learned my first programing language (Fortran IV) using punch cards. I would write the code on a pad of graph paper, using the first 80 boxes as columns. From there, I would type the code on an IBM card punch machine which was similar to typing on a PC in and IDE. Only there was no color coding, auto tabbing or dropdown menu selection boxes. And no lowercase. The 'stack' of cards as we called it, was much like a computer stack in ASM, lol. It had all the cards in descending order: first card (code line 1) then card 2, 3, 4, etc. To accomplish this, the stack was in normal descending order as you would expect, then the entire stack fed through the card reader upside down. The exception was that there was two stacks of cards: the program stack and the data stack. The program stack would be fed in first, then the data stack next with the first card being the data stack identifier for the computer to understand that the following cards were the data and not interpreted code. The computer we used was the IBM 360. After the code was run, you would get an 80 column wide dot matrix print out of the results. Usually, it started with the code then the printed data stack and then the dreaded line that read something like, "SYNTAX ERROR LINE 234. EXECUTION TERMINATED. Yes it would scream that at you because, again, no lowercase! lol You would then have to go figure out what the error was. It was not always on the stated card because it could have been a logic error on a previous card up the stack. Normally, it was that exact card and you just simply re-punched it and replaced the faulty card and ran it again. Hoping you would not get another syntax error further up the stack! It was the best time of my early programming life and I would not want to have changed it. You learned so much about computer science while learning to program. A few years later we went from punch cards to timesharing terminals which was also load of fun! :)
1970. I lived in the dorm so I had access to the punch card machine and the computer office at 2:00 AM so I could get access. When you retrieved the cards from the cardbasket, you immediately rubber banded them so that if you dropped them they would not spread all over the place. If you did drop them, it was easier to re punch rather than trying to get them back in order. You would type very slowly and carefully because there was no going back to correct a mistake. Now, as a hobbiest, I use Thonny for my Python and micropython.
I went to George Westinghouse HS in Brooklyn NY next door to Brooklyn College. Our HS Computer science classes used the IBM mainframe in the college. It was awesome. The first computer i programmed was with punch cards. 1973
As a PhD student in the mid '70s one of the other PhD students, a rather clumsy fellow, wanted to use a programme on a computer at Cambridge University to process his data. He put his data onto a few thousand punched cards (punch is not an adjective) and went off by train to Cambridge. The inevitable happened: he tripped and scattered the cards across the railway carriage. He had not printed sequence numbers on the cards, so could not feed them through a sorting machine.
I once worked for an organisation that had its head office and data centre in one place, and some of its customer service offices in a few neighbouring towns.
One of my former colleagues there, whom had worked for the company for decades already, told me that he had once been asked to drive a van from the head office to one of the customer service offices to collect some punch cards. So he did, and once there he just carried several boxes of these cards into the van and started heading back.
As he was driving, he looked in his rear-view mirror and was horrified to see pieces of cardboard flying in the air behind the moving car. It turned out that, of course, he had forgotten to close the back doors of the van properly, so some of the punch cards had flown out. He was convinced he had just caused a major problem - and, indeed, he had!. Luckily, though, no one on the scene had really understood what had just happened. So he just did his best to collect the cards from the street and drove off without much notice or consequence.
I guess people didn't care much about data safety back then... And I guess we haven't learned too much about it ever since :D.
And that was the early form of the data leak.
Fascinating, as always! In my past at the University of Vienna, the machine (CDC Cyber 73) had the opportunity to number your cards sequentially in the first columns, giving away some space for code. The deck always started wth control cards, stating the operatig system, the compiler,... , and an optional sorting command. If you dropped the shoebox with your cards, you could just feed the mess in any order, and the machine did the sorting before execution in memory (or possibly hard disk). With midframes, such as the PDP-11, we used teletypes and the waxed stripes with the holes, which already was ASCII. The PDP-11 was a very common machine in scientific data acquisition, and in the 70ies we had Textronix monitors with already 4096 x 4096 resolution, which of course was vector graphics. But that is already off topic :-).
I dropped a shoe box almost cried PL1 code for a project.
The last year my college used a punch card computer was in 1985 - 1 year before I went. They sold that system in 1986, when I was a freshman.
My grandfather was an mechanical engineer and one of the patents he received was for a machine to electroplate silver traces on a circuit board 1/64 of an inch high by 1/64 of an inch wide and was controlled by punch cards. This was used to make some circuit boards used in some of IBM's computers.
14:25 Row X and Y were unmarked to allow printing of the characters on the card using an IBM 557 Alphabetic Interpreter or IBM 552 Alphabetic Interpreter. The IBM 557 translated holes punched in cards and printed the corresponding alphabetic, numerical, and special character data on the face of the card on two lines: one line across the top of the card and one line between the Y and X punch rows at a rate of 100 cards per minute at 60 characters per line. The IBM 552's speed was 60 cards per minute.
I remember seeing a NCR computer around 1988 or 1989 still being operated with punch cards to do all the business and client accounting for a credit union, consumer store, industrial complex and agricultural coop marketing as one integrated entity. They had about half a dozen or so operators who exclusively made the punch cards with the transaction data. And they had three punch card readers, with a dedicated operator each, to load the data. Their whole COBOL program was essentially built by a single programmer. And for long term storage they used tape reels.
Ah a trip down my magnetic core memory lane. For Fortran col 6 was statement continuation character
Columns 1-5: Typically used for statement labels.
Column 6: The continuation indicator.
Columns 7-72: Where the actual Fortran instructions are written.
Columns 73-80: Usually ignored by the compiler and can be used for identification purposes like card sequence numbers.
I recall a computer by Univac had a panel of buttons with lights that the op would enter directly in binary for each addressed location in memory. A switch set the data into magnetic core memory that was built much like beadwork using copper thread. I also remember roles of punched paper tape 1" wide similar to what a reel of magnetic tape would look like, with punched code 8 bits wide. The Univac had memory modules as large as bricks, the CPU was larger than most household refrigerators, and the entire system took up the space of a full kitchen.
In my first programming course in college, I programmed a DEC PDP-8 in FORTRAN using Hollerith cards. Those where the days when was possible to accidentally drop a program (a sorted deck of cards) on the floor and scramble it. But that never happened to me, because I was a very good programmer.
One forgotten step in punchcards: in the mid 60s punchcards with outdated accounting data where used for playing around by a 3yo kid in the parents basement. That was the start of an IT career still about to last 5 more years till retirement. And more than 10y was on mainframes, that still today think they read punchcards. If you wonder, look at the JCL (job control language).
BTW, most computers use ASCIi (or the superset Unicode).
Most, but the ones that still run batches of (virtual) cards.
Fascinating video. I used a punch card machine for my Fortran class homework in college during the last '70s. I can speculate that you had a hard time finding documentation about how all this worked because it was a horrendous system. Like an abusive childhood, no one wants to remember it. Besides the horribly awkward, slow methodology of making the cards, it wasn't like you submitted this job and got to see the result in real time. The computer center would run it overnight, then put a printout of the results in the computer room the next day. The first time you submitted your job, it was almost certain there would be errors in the code that prevented it from running. I often had to do several rounds to get the program to run at all. And all this is before determining if the program was putting out the correct answer. It was awful. What we would now call a trivial program would take days to get the proper output. I don't know how computer programmers did their work back then.
By the time I switched my career to being a software engineer, punch cards were blissfully residing in their grave. We can be grateful that they started the computer revolution, but even more grateful that they were supplanted by terminals where we could develop code on the screen.
Been there, done ALL that! Nice write-up of how bad it was back in the day. When I started writing code on a dumb terminal, dialed into CP/67 running on an IBM 360 mainframe using an 800-baud acoustic coupler modem, it was transformative not having to deal with card decks. And don't get me started about how futuristic those first IBM 3720-series full-screen terminals were when we got our hands on them. None of had any idea of what was to come as tech advanced faster and faster. I'm glad I witnessed the massive evolution in computing from a primitive stone age to where we are today.
We used to have a Sperry Univac 2200 system at UWC and to remember one day it needed a restart and they had boot it from a deck of cards … it was the IPL Inital Program Load sort of like the BIOS
1984 .. they still had a card reader in the computer lab
I knew I was officially old when another programmer asked me, “what’s a punch card?”
One of the reasons IBM was more successful than other firms is that they made their computers compatible with other machines. The character set is an example of this. EBCDIC (Extended Binary Coded Decimal Interchange Code) is an example of this. It was an extension of the character set used to transmit text on phone lines.
And today their big irons are the only ones to use (virtual) EBCDIC punchcards to read the JCL to start a Linux partition 😂
I was a Telecommunications Specialist with the United States Air Force in the 1970s. I worked in the Autodin system in England. It was the computer to computer digital switching center based com system of the time that was the precursor of the present day Internet. It was my job to troubleshoot com link outages and direct corrections. Each circuit outage required a slip to be filled out if an outage went over ten minutes. At the end of the day all slips were made into Hollerith cards for computer reading. The data on circuit outages were in that way collated and sent back to Andrews Air Force base in the United States for analysis and action. I was never good at typing these damned cards up correctly and had to do cards over again. 😀
Great video. One of the best overviews of technology history I've seen in a while. Fortran was my nightmare of choice back in the day. SOOOoooo much better now.
Even earlier than that, programs were like breadboard circuits, so programmers were literally setting the logic using wires, connecting contacts in the machine. A rack-like device with an array of holes was the frame, and wires with a plug on each end were used to connect the holes. Then the rack was slid into a holder which was swung down on an array of contacts. That is where the term 'bug' originated. An early programmer was Grace Hopper, who had wired up a program, which would not work, and when to find out why she lifted up the rack she found a moth stuck between a plug and a contact, and because Americans call such insects 'bugs', from then on whenever a program would not work they would look first for a bug.
Girrlll...I've got my popcorn🍿 and getting ready to enjoy this like a blockbuster movie... so good!☕
We used punch cards in around 1979 on a single Apple II in my 6th grade computer class, but the type you can use a #2 pencil with. We did that because we only had 1 computer, but 5 students, so we could write our software on the cards. Then we would reserve time on the computer to load the programs with a card reader and debug our software.
This is how I started - and I am still coding in Assembler and COBOL today.
I also remember learning COBOL in 1991 with those coding sheets. They were almost 14 inches wide by 11 inches high, with the coding grid pre-printed in orange ink. After writing our program with a plain pencil on the coding sheets, and getting the verification from our instructor, we would then transcribe that program with vi on a Unix terminal for subsequent compilation and execution in the same Unix terminal.
I used a Fortran compiler that could produce a “compressed punch card deck” with sequence numbers during the compilation. This gave me a backup of my Fortran program which could be sorted if I dropped it. The Fortran compiler could also compile from a compressed deck along with update cards when changes were needed. The “compressed deck” was analogous to “gzip” but for punch cards.
I did some FORTRAN on Punch Cards at university in 1980. The cost of a Time Share Terminal was out of my budget, so punch cards were the way to go.
Dee, I appreciate very much watching your videos on computing. But you did a disservice to women's accomplishments in the history of all computing. You mentioned Charles Babbage being the person who invented (on-paper only) the steam-driven computing machine that is now called the Analytical Engine (later, he designed a better version, the Difference Engine). However, he was just an engineer, and he did not know much about algorithms, computing, or programming. Enter on-stage his best student: Ada Augusta King, aka Ada Lovelace. Ada (the daughter of Lord George Gordon Byron, the [in]famous poet) created the world's first programming language, based on Babbage's designs. Ada's notes included a sequence of program steps to calculate Bernoulli numbers, and how to adjust the settings on Babbage's machine to do such calculations. In other words, she wrote the first computer program designed for an interoperable, programmable computer.
Yeah I was expecting Ada to get a mention plus all the female "computers" before men came into programming
Around 1985 I programmed on punched cards at school. The program was then sent off to a local university and we got the results back the next week.
I used punch cards in college in the early 80's, and at a job at McClellan AFB, where they had some super old computers. I don't remember now the model of the computer at McClellan, but I do remember they had to get rid of it when IBM said they would no longer maintain it, it was too old. I heard it went to the Smithsonian. I've used paper tape, computers with core memory, and drum memory. Fortunately, I didn't use any of those for too long, as terminals were just starting to be a thing.
Took a Fortran class in 1980; we had to use punch cards and card readers. By 1985, took a SPITBOL class and you could write all of the code on a terminal, which was much easier. That's assuming, of course, that a functioning terminal was available.
I've done a lot of punch card programming. Had the batch cards and then the data cards. Boxes. Then carry them to the mainframe building. An error, and a new card in its place. It worked.
I remember recycling the punch cards at a paper mill. They came in on a pallet in a pallet sized open top cardboard box. Good fiber. It recalled memories of being in the basement in Hughes Hall at Miami University turning in those cards for my Fortran course.
Yeah, I'm 60+ and I used that equipment - she doesn't look old enough. Programming tended to be different then for another reason - students had to know how to write their programs on paper, flowchart, desk check until they could punch. Now students don't even know Structured Programming before turning on their computer and typing into a Rapid Application Development tool where they find they have errors they can't figure out. Schools, in their effort to churn out graduates in minimal time, don't have courses explaining the basics of programming.