Difference between revisions of "Talk:1755: Old Days"

Explain xkcd: It's 'cause you're dumb.
Jump to: navigation, search
(Mailing programs to IBM...not far from the truth.)
Line 13: Line 13:
  
 
I think the punched cards explanation is missing the point that C (or any language, that I know) didn't _require_ that it be on punched cards.  I.e. there was nothing in the language specification that prohibited the program from being on paper tape, mag tape, disk, etc. [[Special:Contributions/162.158.74.70|162.158.74.70]] 14:22, 4 November 2016 (UTC)Pat
 
I think the punched cards explanation is missing the point that C (or any language, that I know) didn't _require_ that it be on punched cards.  I.e. there was nothing in the language specification that prohibited the program from being on paper tape, mag tape, disk, etc. [[Special:Contributions/162.158.74.70|162.158.74.70]] 14:22, 4 November 2016 (UTC)Pat
 +
 +
 +
: I strongly echo 141.101's recollections.  The second panel of 1755 is not far from the truth.
 +
 +
: I wrote my first program in FORTRAN IV in 1972 in an "enrichment" class at my school in Worthing - in the south of England (it calculated the average of 10 numbers).  We wrote the programs out by hand on 80 column "coding forms" which were then snail-mailed to the regional computing center.  When their keypunch operators had time, they'd punch our programs onto cards.  On the following night, after the payroll software had been run, they'd stick our cards into the batch queue of their over-worked IBM 360.  If they compiled, the programs would auto-run and would be allowed to produce at most 6 sheets of line-printer paper of output.  If they didn't compile, then the first six pages of source code and error messages would go to the printer instead.  The following morning, someone would collect our printouts and snail-mail them back to the school.
 +
 +
: If you had a compile error, you'd have to copy everything out onto fresh coding forms and re-submit it.
 +
 +
: When the "unofficial" project to teach programming to 14/15 year-olds ran low on cash, they switched to 2nd class mail in each direction.  We did two programming classes a week but we'd be VERY lucky to get a turnaround time of less than a week.  So the line on panel two:  "To compile your code, you had to mail it to IBM, took 4-6 weeks"...isn't *that* much of an exaggeration!  We mailed it to the regional computing center - and it rarely took more than 2 weeks...but what she says isn't very far from the truth!
 +
 +
: In practice, things never went smoothly.  The keypunch operators didn't routinely type FORTRAN code - they mostly entered stuff like names and addresses, that are somewhat tolerant of typo's.  If you were struck by a typo, you'd have to just resubmit the exact same coding forms and hope you didn't get a typo on the following week!  Since it was only a 10 week course, you got VERY good at writing your coding forms up clearly, to NEVER forgetting to slash your zeroes and put serifs on your I's...making 100% sure your code would compile first time around was essential to getting anything to run.  We quickly learned that using "I" as a loop variable was worse than (say) "COUNT" because it was more likely to get mis-typed as a '1'.
 +
 +
: I begged and pleaded to be allowed to do the same course for two years running but on the second year, the keypunch operators finally rebelled at the extra work we were giving them as our programs grew larger and more ambitious.  So we were instructed to punch our own cards using a "hand punch" machine where you manually held down a "chord" of keys to punch raw binary into the cards.  Get just one bit wrong, and you had to toss out the entire card and start again.  It would take multiple hours to punch in even a very short program!  Gone was the idea of using "COUNT" for a loop variable!  The idea of commenting your code became simply ludicrous - so the teacher told us to write comments onto blank cards and stick them into the deck where needed!
 +
 +
: Because of that horrendous problem, the concept of "code-reuse" was important!  If you could re-use some of the cards from a previous program, or '''''borrow''''' a subroutine from a friend (they'd want it back afterwards!), you'd save yourself a mountain of time!  Decks of handy subroutines had value...you could exchange them for all sorts of playground "items-of-value" with the other geeks who did the class.
 +
 +
: I'm tempted to say that this taught me a lot about the art of programming and the importance of checking your code and writing for re-use...but I rather doubt it.  When I finally got to my second year in college, I had access to a PDP-11/20 with DecTapes and a DecWriter terminal, that's about when I started to learn something useful...and in my final year, 1977 - I was finally granted access to the PDP-11/70, UNIX and a ADM 3a "glass teletype".  I could really get to learning the craft that's still paying my mortgage 40 years later. [[User:SteveBaker|SteveBaker]] ([[User talk:SteveBaker|talk]]) 14:25, 4 November 2016 (UTC)

Revision as of 14:25, 4 November 2016


Reflections on Trusting Trust (pdf), Ken Thompson's acceptance speech for the 1984 Turing Award, in which he discusses creating a backdoor in the C compiler (yes, there was only 1 when he invented the language) that itself creates a second backdoor in the login program when it is compiled. Additionally, it reproduces itself when compiling the C compiler from un-tampered-with source code, so that anyone using the binary (compiled) compiler would be unable to avoid reproducing the backdoor in all its forms. This is the sort of thing that gives security programmers nightmares. 108.162.221.168 04:52, 4 November 2016 (UTC) (bonsaiviking)

The "4-6 weeks" thing might be a reference to high-performance computing, in particular scientific calculations, a few decades back. From what I've heard from older people in my scientific field (I'm too young to have experienced it myself), you'd prepare your program on punch cards, mail these to an institution owning a fast computer (because your group or university didn't have one), and they'd run the program and mail the result back to you. This, I've been told, took a few weeks. Maybe someone with first-hand experience can give more information. 141.101.104.98 10:34, 4 November 2016 (UTC)

Source Code on Punched Cards: As an undergrad at Durham Uni I remember punching PL1 source code onto cards to be inserted into a batch queue to be compiled and run on an IBM360 at the nearby city of Newcastle, overnight. 141.101.98.160 11:57, 4 November 2016 (UTC)

At the risk of emulating Dilbert's "Topper", I remember at school writing programs on coding sheets (effectively squared paper; one character in each box), which would get sent to the local university, where they would be punched onto cards and run on the mainframe. The following week, you'd get your coding sheets back, plus the cards and the printout from your batch job. Then you'd make your corrections, also on coding sheets... 141.101.98.143 13:35, 4 November 2016 (UTC)

I'm reminded of Frank Hayes' song, "When I Was a Boy": "And we programmed in ones and in zeroes / And sometimes we ran out of ones!" On a more serious note, C came out in the late seventies, and I was using punch cards as late as 1975. That's not "long" before, and I wouldn't be too surprised if there were C compilers that accepted punched card input. Gmcgath (talk) 12:27, 4 November 2016 (UTC)

I think the punched cards explanation is missing the point that C (or any language, that I know) didn't _require_ that it be on punched cards. I.e. there was nothing in the language specification that prohibited the program from being on paper tape, mag tape, disk, etc. 162.158.74.70 14:22, 4 November 2016 (UTC)Pat


I strongly echo 141.101's recollections. The second panel of 1755 is not far from the truth.
I wrote my first program in FORTRAN IV in 1972 in an "enrichment" class at my school in Worthing - in the south of England (it calculated the average of 10 numbers). We wrote the programs out by hand on 80 column "coding forms" which were then snail-mailed to the regional computing center. When their keypunch operators had time, they'd punch our programs onto cards. On the following night, after the payroll software had been run, they'd stick our cards into the batch queue of their over-worked IBM 360. If they compiled, the programs would auto-run and would be allowed to produce at most 6 sheets of line-printer paper of output. If they didn't compile, then the first six pages of source code and error messages would go to the printer instead. The following morning, someone would collect our printouts and snail-mail them back to the school.
If you had a compile error, you'd have to copy everything out onto fresh coding forms and re-submit it.
When the "unofficial" project to teach programming to 14/15 year-olds ran low on cash, they switched to 2nd class mail in each direction. We did two programming classes a week but we'd be VERY lucky to get a turnaround time of less than a week. So the line on panel two: "To compile your code, you had to mail it to IBM, took 4-6 weeks"...isn't *that* much of an exaggeration! We mailed it to the regional computing center - and it rarely took more than 2 weeks...but what she says isn't very far from the truth!
In practice, things never went smoothly. The keypunch operators didn't routinely type FORTRAN code - they mostly entered stuff like names and addresses, that are somewhat tolerant of typo's. If you were struck by a typo, you'd have to just resubmit the exact same coding forms and hope you didn't get a typo on the following week! Since it was only a 10 week course, you got VERY good at writing your coding forms up clearly, to NEVER forgetting to slash your zeroes and put serifs on your I's...making 100% sure your code would compile first time around was essential to getting anything to run. We quickly learned that using "I" as a loop variable was worse than (say) "COUNT" because it was more likely to get mis-typed as a '1'.
I begged and pleaded to be allowed to do the same course for two years running but on the second year, the keypunch operators finally rebelled at the extra work we were giving them as our programs grew larger and more ambitious. So we were instructed to punch our own cards using a "hand punch" machine where you manually held down a "chord" of keys to punch raw binary into the cards. Get just one bit wrong, and you had to toss out the entire card and start again. It would take multiple hours to punch in even a very short program! Gone was the idea of using "COUNT" for a loop variable! The idea of commenting your code became simply ludicrous - so the teacher told us to write comments onto blank cards and stick them into the deck where needed!
Because of that horrendous problem, the concept of "code-reuse" was important! If you could re-use some of the cards from a previous program, or borrow a subroutine from a friend (they'd want it back afterwards!), you'd save yourself a mountain of time! Decks of handy subroutines had value...you could exchange them for all sorts of playground "items-of-value" with the other geeks who did the class.
I'm tempted to say that this taught me a lot about the art of programming and the importance of checking your code and writing for re-use...but I rather doubt it. When I finally got to my second year in college, I had access to a PDP-11/20 with DecTapes and a DecWriter terminal, that's about when I started to learn something useful...and in my final year, 1977 - I was finally granted access to the PDP-11/70, UNIX and a ADM 3a "glass teletype". I could really get to learning the craft that's still paying my mortgage 40 years later. SteveBaker (talk) 14:25, 4 November 2016 (UTC)