1755: Old Days

|< < Prev Comic #1755 (November 4, 2016) Next > >|

Old Days

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.

Explanation

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. This later became a series when 2324: Old Days 2 was released more than 3.5 years later. While her initial agreement that code needed to be compiled for multiple architectures is correct, Hairbun's claims rapidly grow ridiculous.

Hairbun tells Cueball a tall tale 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 in the mail to a computer company (IBM in this case) to compile your code, which would take from four to six weeks. If there was a simple error, you would have to ship it again for another compilation.

This is factually incorrect, but is plausible to those who do not have the knowledge or context to challenge it, similar to a Snipe hunt, or several other cultural myths told about things like the Tooth Fairy. It is clear from Cueball's final Wow that he falls for it. She then continues to explain more and more implausible so-called facts from the the olden days.

What she says is true in that it was tough and slow to program on punch cards, which were actually used for an extended period of time. However, there is very little in the rest of Hairbun's story that accurate, except that it was a big deal when the floppy disk was invented. The comment about punching holes in floppy disks is true. However, the nature and purpose of the holes punched this way was dramatically different than in punch cards. 5.25" and 3.5" floppy disks had holes or notches in them to indicate the data capacity and it was common to punch additional holes into cheaper, lower capacity floppy disks to trick the computer into writing more data on them than specified by the manufacturer. With punchcards on the other hand, the holes themselves encoded the data so punching them was itself the act of programming. It is unclear if this was a coincidence, or intentionally included as a humorous aside to the readers who know the history as a misinterpreted truth in a sea of falsehoods.

In the title text, Hairbun continues her musings on the old compiler days, stating that there was a lot of drama in those days. Specifically she 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 had thought of this, then Thompson's paper was there for any future hacker to see. Though the problem was (claimed to be) solved in David A. Wheeler Ph.D dissertation "Fully Countering Trusting Trust through Diverse Double-Compiling (DDC)".

Table of statements

Statements	Concepts used	Explanation
Compile things for different processors	Compilers convert code from a human-readable programming language into a binary code that can be directly executed by computer processors.	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, programs needed to compile directly into the native machine language for each processor they were intended to run on. Native machine language is dependent on processor architecture. Therefore different processors designed around different architectures will not run the same compiled code (unless the architectures are compatible; AMD64 processors will run i386 code natively, for example.) If the same code needs to be run on multiple architectures, it must be compiled separately for each supported architecture.
To compile your code, you had to mail it to IBM. It took 4-6 weeks.	Similar to sending Kodachrome slide film to Kodak to be developed.	While IBM has released multiple compilers, they sent the compiler to you, you did not send the code to them. There is some kind of truth in the statement, though: when programming on mainframes, programmers submitted their source code in the evening for compilation overnight. When there was an error in the code, they did not get a compiled version of it back, and had to resubmit their code. Sometimes there were time slots available for compilation, and in universities, students would have to wait for their next time slot for another try.
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 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 itself 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 of the source code; it is tagged such that the compiler will discard it to save space. 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. But sometimes the comments are written in a certain way to compile documentation automatically from it. Also, when examining the output of compilers it's a common practice to use assembly code annotated with comments containing the source code of the program from which the assembly code was generated. Hairbun's comment is thus very strange, implying the compilers of the day could only distinguish between comments and code if assembly was used to insert the separating tags.
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 early form of storing data; the pattern of holes and non-holes in a paper or cardboard card represented information.	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 were being replaced by magnetic storage and text editors by 1972, when C (or C++) was developed. This site demonstrates a card punch and cards: Keypunch. Hairbun claims that code was not written using keyboards, but by punching out letter and character shapes in the punch cards, and the computer would read keystrokes that way. Simply put, this was never true. 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 form of storing data magnetically. It's way more advanced than punch cards (by several orders of magnitude; a card can store about 80 bytes, vs 1,474,560 bytes of a floppy disk), but it's still obsolete compared to modern storage.	Hairbun says that the improvement from C to C++ was that 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 programming was to make holes in floppy disks rather than punch cards. This would of course not be an improvement as floppy disks store information magnetically, as opposed to physically, as punch cards do. This is likely a play on the concept of punching holes in 5.25" floppy disks to double their storage (see Double-sided disk), or it can also be a reference to the "index hole" of 5.25" floppy disks (see Floppy disk Design and the tiny hole at the right of the big central hole in this image). A notch in the side of 5.25" floppy disks indicates when the disk could be written. Though many floppy disks were intended to have only a single side with data, many people used a hole punch to notch the opposite side of the disk, allowing a drive to write data to the other side of the disk in a single sided drive. 5.25" floppies also featured a tiny "index hole" near the central hole of the disk.

Transcript

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

 add a comment! ⋅  add a topic (use sparingly)! ⋅  refresh comments!

Discussion

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)

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)

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)

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. 162.158.74.70 14:22, 4 November 2016 (UTC)Pat

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. 162.158.75.64 (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 --172.68.51.70 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. -- 108.162.246.42 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. 108.162.237.88 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* --172.68.78.133 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 --162.158.88.254 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. 162.158.69.160 18:39, 7 November 2016 (UTC)

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