Programming with Punched Cards (2005) [pdf]
columbia.edu
columbia.edu
Later, to avoid other courses with punchcards, I used a combination of Emacs at MIT-AI over the Arpanet, a terminal emulator written in Z-80 assembly and a DEC-10 at my co-op job. It was worth driving 30 miles to pick up printouts to avoid punching cards and waiting hours for my programs to turn around.
The 'art' of desk checking is invaluable to some of us while others prefer the 'suck it and see', or the 'push and pray' approaches. They all have their place, but if one is isnt a math geek then desk checks are the best way to 'prove' out the code and find bugs.
I went thru Uni Comp Sci mostly using cards for everything, we all shared card punches, even today an 029 punch has a 'feel' to it I haven't forgotten
Reminds me if the time I was using the Naval Electronics Labs' (San Diego) mainframe as part of an Explorer post, semi-officially during high school (1971-ish), and got ambitious, writing a compiler in the assembly macro language. Wrote it up on the punch card forms, several thousand lines of code. Submitted it to the punch card crew, and got it back several days later with a rather strong note about what project to charge it to. Turns out it was quite expensive to punch several thousand cards and they expected our group to be submitting little programs in Fortran, not monster assembly decks.
Oh well, somehow it was glossed over. They ended up hiring me that summer to do some systems programming so I guess they weren't too mad.
I hacked a primitive full text editor on a Sperry Univac mainframe but it was dis-allowed on account of eating up too much machine time. After each keypress it would hit 'submit screen' rather than at the end of a round of editing in the on-screen text buffer. It worked but the resource consumption was off the scale. So this kind of editing had to wait until we all had machines powerful enough on our desks to run an editor directly.
The early terminals were hardcopy. The Teletype 33 terminal [1] was popular and so were the IBM 2741 and Digital DECwriter. These worked fine and were better than punching cards, but they couldn't be used on many systems. I saw these mostly on minicomputers where there was only a handful of people (often just one) using the computer at a time.
The most dominant mainframe operating systems from around this time (IBM 360 MFT, MVS) were not capable of handling I/O interrupts efficiently enough to support a number of users working at terminals. The hardware and operating systems of these mainframes were designed around an architecture that supported batch processing: read in a program from a deck of cards, read in the data from a large stack of cards, run the program for minutes or hours, print out the results on a line printer.
A properly sized mainframe would be running jobs continuously throughout the day and most of the night, but it would be (mostly) running one job at a time. These early operating systems and the hardware I/O bus designs supported batch processing well but wouldn't have supported large numbers of concurrent programmers sitting at there own terminals connected to the system.
The rise of timesharing operating systems like Multics and Unix provided additional impetus for video display terminals (VDTs), but it wasn't until around 1976 that really affordable VDTs were even available. The ADV 3 was a nice terminal that came out in 1976, see [2]. I couldn't afford one, but I knew someone that had one and was able to work from home over a 300 bit/sec acoustic modem. It had 24 lines of 80 characters (from the 80 columns that cards had). It wasn't until 1978 that the DEC vt100 was produced.
In 1984, I was in software development at IBM and we were still using the 3270 terminal [3]. This terminal was connected to a mainframe timesharing system that still had trouble processing each keystroke as it was typed. Instead, the IBM 3270 was a block or page oriented terminal where you filled out the screen of text and then pressed the transmit key to send the whole screen full of text to the system in one transmission.
[1] https://en.wikipedia.org/wiki/Teletype_Model_33
Baby programmer. As an undergrad we were thrown into the deep-end and given those green/white programming sheets, pointed to the computer centre with its rows of 029 keypunch machines and let loose. This is what a keypunch looks like up close: https://www.flickr.com/photos/bootload/247968267/
While we had a micro-computer lab, we still had to use the Cyber mainframe to program with FORTRAN for data crunching map data. You really worked hard on your code. One mistake, one mistyped character and your printout was all debug. A year into my first startup, ten years later I missed the break-up of this machine. [0]
If I look over on my bookshelf, I still have a couple of decks. That's what I remember most. Card decks and rubber bands. Fun times.
And still have an EOF card as a bookmark in my old COBOL book
More fun could be had with card patches (used for corrections) and card saws (used for clearing the worse jams -- no, I'm not kidding.)
The best card patches were transparent or conductive tape, because they'd be read differently by optical vs. brush-contact readers, and many shops had both.
The IBM 1443 printer used a "type bar" instead of a chain...
http://archive.computerhistory.org/resources/still-image/ibm...
https://www.staff.ncl.ac.uk/roger.broughton/museum/iomedia/p...
...on occasion a column hammer would stick (they were operated by electromagnets) and some of the little sets of metal type would pop out of the bar. Note that the woman is holding two bars; one with more type on it than the other. That's because there were two bars: the "13-character" (0-9, +, - and $) and the "43-character" (26 alpha, ten digits and +-=.()$ ) bars, and the 13-character bar printed much faster because it didn't need to move as much to put every character in front of every column hammer.
When a type segment popped out, it could get lost inside the machine, and a supply of replacement type segments were at hand. One night (at a bank) the segment on a 43-char bar that had the numbers on it popped out and was lost. The operator on duty duly replaced it with a spare...which turned out to be from a 13-char bar.
It had all the numerals on it.
In different places.
So all the numbers on the bank's transaction journal and general ledger balances had almost-randomly wrong digits in them sometimes, depending on where in the stroke the bar was and which direction it was moving in for that line on the report.
Good times...
Must have been a "accidentally turing complete" moment. http://beza1e1.tuxen.de/articles/accidentally_turing_complet...
I'm still a software engineer. Take my word for it: it's good