1755: Old Days

Explain xkcd: It's 'cause you're dumb.
Revision as of 12:20, 4 November 2016 by (talk) (Table of statements: Punch cards have no font)
Jump to: navigation, search
Old Days
Lot of drama in those days, including constant efforts to force the "Reflections on Trusting Trust" guy into retirement so we could stop being so paranoid about compilers.
Title text: Lot of drama in those days, including constant efforts to force the "Reflections on Trusting Trust" guy into retirement so we could stop being so paranoid about compilers.


Ambox notice.png This explanation may be incomplete or incorrect: More explanation required on computer programming. Fill out the explanation column in the table that lists all the statements.
If you can address this issue, please edit the page! Thanks.

This comic is showing a conversation between (young) Cueball and (old) Hairbun about computer programming in the past specifically the compilers. Cueball, having a faint idea of just how difficult and byzantine programming was "in the old days", asks Hairbun to enlighten him on the specifics. Hairbun promptly seizes the opportunity to screw with his head.

While her initial explanation that code needed to be compiled for multiple architectures is correct, Hairbun's claims rapidly grow ridiculous to the point where the improvement from C to C++ was the C++ finally supported floppy disks but just used them to punch holes in rather than using punch cards "like C used".

What Hairbun does is to mess wit Cueball, who addresses her as if she is very old. She tells him a tall story about how hard it was back in the Old Days, making it sound like some of the programming languages used today (C, C++) were written on punch cards, and that you had to ship your code with the mail to get a computer company (IBM in this case) to compile your code, which would take a month. Too bad if there was a simple error and you had to ship it back for another compilation.

Nothing of what she tells Cueball makes any sense, but it is clear from Cueball's final Wow that he falls for it, ready to believe anything the old Hairbun tells him about how horrible it was to program in the olden days. It is true that it was tough and slow to program on punch cards, which where actually used for an extended period of time, but there is nothing in the rest of Hairbun's speech that makes any sense with regards to the old days, except that it was huge when the floppy disk was invented.

In the title text Hairbun continues her musings on the old compiler days, stating that there where a lot of drama in those days. Specifically the references Reflections on Trusting Trust a famous 1984 paper by UNIX co-creator Ken Thompson in which he described a way to hide a virtually undetectable backdoor in the UNIX login code via a second backdoor in the C compiler.

Using the technique in his paper, it would be impossible to discover the hacked login by examining the official source code for either the login or the compiler itself. Ken Thompson may have actually included this backdoor in early versions of UNIX, undiscovered.

Ken Thompson's paper demonstrated that it was functionally impossible to prove that any piece of software was fully trustworthy.

Hairbun claims that one of the dramas she refers to was that people tried to force Ken Thompson to retire, so everyone could stop being so paranoid about compilers. In reality, any coder who created the first version of a compiler (or a similar critical component) could inject a similar backdoor into software, so it would be false safety. Even if no one else would have thought of this, then Thomson's paper was there for any future hacker to see. Though the problem was (claimed to be) solved in David A. Wheeler PhD dissertation "Fully Countering Trusting Trust through Diverse Double-Compiling (DDC)".

Table of statements

Statements Concepts used Explanation
Compile things for different processors Compile? Many popular modern programming languages are either interpreted - meaning that they run directly from source code - or compile to an intermediate bytecode, like Java or common Python implementations. Programs written in such languages are portable across processor architectures - x86 to ARM, for example. Lower-level languages must take into account the features available on a given processor architecture and operating system. Before that, even, programs needed to compile directly into the native machine language for each processor they were intended to run on.
To compile your code, you had to mail it to IBM. It took 4-6 weeks. While IBM has released multiple compilers, they sent the compiler to you, you did not send the code to them.
Before garbage collection, data would pile up until the computer got full and you had to throw it away. A Garbage Collector is a piece of the software that cleans the RAM memory of data that is no longer being used in the execution of a program. Garbage collection is a form of memory management that generally destroys objects or frees up memory once a program no longer needs it. In languages without automatic memory management, like C, the program must keep track of what memory has been allocated, and free it once it is no longer needed. If the program does not, it can end up trying to use more memory than the computer has, and may crash. This was, however, a temporary condition. In the worst case, a simple reboot will clear the computer's memory.
Early compilers could handle code fine, but comments had to be written in assembly. A comment in programming is a text written in natural language that is meant to explain some feature on the source code. Assembly is a low-level programming language. Comments, in code, are portions of one or more lines that are ignored by the compiler. They are commonly used to explain or comment on the code itself. It does not make any sense to write a comment in any programming language
C could only be written on punch cards.You had to pick a compact font, or you'd only fit a few characters per card. C is a programming language. A punch card is a primitive form of storing data; it stored data in binary language with holes in a paper or cardboard card where a hole meant a 1 and the absence of a hole meant a 0. While punch cards were used through the late 1970s and early 1980s to enter programs and data in COBOL, FORTRAN and other early languages, the use of punch cards and punch card machines had been replaced by a Text Editor long before C (or C++) was developed as a language.

Also, as punch cards store characters in binary, there is no font involved and they store up to fixed limit of characters per card (80 characters in the most common format.)

C++ was big because it supported floppy disks. It still punched holes in them, but it was a start C++ is a programming language. A Floppy disk is a (more advanced than punch cards but still old) form of storing data magnetically. Hairbun says that the improvement from C to C++ was the C++ finally supported floppy disks. but then it turns out that in C++ the floppy disks were just used instead of punch cards. So the programing was to make holes in floppy disks rather than punch cards. This would of course not be an improvement as floppy disk are not as easy (actually very hard) to make holes in, compared to punch card, which are made for this purpose and then the whole concept of using floppy disk to store data magnetically is ignored. In any case, a hole punched in a floppy disk would render it useless.


[Cueball and Hairbun are standing together and Cueball is talking to her.]
Cueball: What were things like in the old days?
Cueball: I hear that you had to ... compile things for different processors?
Hairbun: Yeah
[Same setting in a slimmer panel, now Hairbun is replying.]
Hairbun: To compile your code, you had to mail it to IBM.
Hairbun: It took 4-6 weeks.
[Close-up of Hairbun from the waist up.]
Hairbun: Before garbage collection, data would pile up until the computer got full and you had to throw it away.
[Same setting as in the first panel with Hairbun gesturing toward Cueball raising one hand palm up.]
Hairbun: Early compilers could handle code fine, but comments had to be written in assembly.
[In a frame-less panel Hairbun is seen from the front, with both arms out to the side with both hands held palm up.]
Hairbun: C could only be written on punch cards.You had to pick a compact font, or you'd only fit a few characters per card.
[Exactly the same setting as the first panel, but with Hairbun doing the talking.]
Hairbun: C++ was big because it supported floppy disks.
Hairbun: It still punched holes in them, but it was a start.
Cueball: Wow.

comment.png add a comment! ⋅ comment.png add a topic (use sparingly)! ⋅ Icons-mini-action refresh blue.gif refresh comments!


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. 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. 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. 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... 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)

Punch cards 79-80 in the U.S. for C programming. We did have text editors too for other languages, but we'd punch up and submit decks to a queue for batch processing. Usually only waited minutes (though the when big projects were due, it could take an hour - the bad part was there wasn't any way to stop an infinite loop until the job limit ran out. We were given so much in "computer dollars" for the class (because the machines were also used for outside work for real money) and you'd have to ask for extra if you used it up. I miss the green bar paper though. Afbach (talk) 18:25, 4 November 2016 (UTC)

Is there a parallel here between computing and real life? For example, panel 3 mimics real life garbage collection, where you let your trashcan pile up before collection. Similarly, without texting in the 'old days' you would have had to mail stuff to people whereas to do things we can do in seconds now. So she's using his views of the -- ExplainBot (talk) (please sign your comments with ~~~~)

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. 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)

Is it just me, or is there a parallel between sending you code off to be compiled and sending your code off to an app store. In both cases a required part of the build is sending your code off to a private company for approval. Olleicua (talk) 15:28, 4 November 2016 (UTC)

Can someone please verify that it is "actually very difficult" to punch holes in floppy disks? Probably it should be attempted on at least 1000 different disks of different kinds to make sure. (talk) (please sign your comments with ~~~~)

Interesting: there exist two versions of this comic with different size https://imgs.xkcd.com/comics/old_days.png and https://imgs.xkcd.com/comics/old_days_2x.png The latter is used when zooming in on the comic's page -- 19:48, 4 November 2016 (UTC)

This is to allow browsers to show a higher resolution image on screens that support it. For example, on my Mac Retina display, which has 2 screen pixels per CSS pixel in each dimension, the comic I see on xkcd's page looks much crisper than the version here. This is because xkcd is using the srcset tag to select the 2x version of the image on high-resolution screens scaled down 50%; or rather, not scaled up by 2x like most other images.
I think this is the first time xkcd has used this feature. I don't recall seeing it before, and comic 1754 doesn't use it. -- 15:29, 6 November 2016 (UTC)

You didn't have to ship the punch cards to a company, but you did have to put them into a queue to be processed, and if you did have a typo or other simple mistake, you'd have to wait to get the output before knowing (which could take days). Most of what she says actually makes sense, it's just not fully accurate. You use to have to manually collect your garbage (making sure you unallocated your memory). You often did have to mix code and assembly (thought not for comments, and would that be // or /* */ or # or...). She also follows computer storage history. So again, not accurate, but it makes sense. 19:56, 4 November 2016 (UTC)

Punch cards did not actually use binary, but a position based coding. Each column (character) had 12 positions where a hole could be punched. Numbers were represented by one hole in the matching numbered row; letters by two holes, one in the upper three row, and one in the lower nine, giving 27 combinations; punctuation and symbols mostly used three holes. I learnt this punching FORTRAN into cards in 1968141.101.98.232 01:14, 5 November 2016 (UTC)

Is there a parallel here between real life and computing? Panel 3 is like the way people wait until their trashcan's full before throwing it out, and panel 2 could reference how you had to mail things to people in the 'old days' instead of texting them, which takes no time nowadays. So, she's using the things he knows were true in the past (such as texting not existing) to make ridiculous statements which sound believable to him. Not sure about the other panels though. ExplainBot (talk) 15:39, 5 November 2016 (UTC)

Back in my day, we lived RFC 1149. Y'all got it easy now. *scoff* -- 13:37, 6 November 2016 (UTC)

... and when we got home, our Dad would kill us, and dance about on our graves singing "Hallelujah." :-D -- 17:34, 6 November 2016 (UTC)

It is not clear to me that the final 'Wow' indicates that Cueball falls for it. Other interpretations include surprise that Hairbun cares so little or that she would go so far, or shock that she thinks so little of Cueball or indignity that she cares so little for his (admittedly ageist) social overture. 18:39, 7 November 2016 (UTC)

....I'm 17 and fell for this completely. I feel naive. 10:43, 7 January 2017 (UTC)