Editing 1755: Old Days

Jump to: navigation, search

Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision Your text
Line 8: Line 8:
  
 
==Explanation==
 
==Explanation==
This comic shows a conversation between (young) [[Cueball]] and (old) [[Hairbun]] about computer programming in the past, specifically {{w|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 [[:Category:Old Days|series]] when [[2324: Old Days 2]] was released more than 3 and a half years later. While her initial agreement that code needed to be compiled for multiple architectures is correct, Hairbun's claims rapidly grow ridiculous.
+
This comic is showing a conversation between (young) [[Cueball]] and (old) [[Hairbun]] about computer programming in the past, specifically the {{w|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 agreement that code needed to be compiled for multiple architectures is correct, Hairbun's claims rapidly grow ridiculous to the point where the improvement from {{w|C (programming language)|C}} to {{w|C++}} was that C++ finally supported {{w|floppy disks}} but just punched holes in them rather than using {{w|punch cards}} "like C used".
  
 
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 ({{w|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.  
 
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 ({{w|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.  
Line 14: Line 16:
 
This is factually incorrect, but is plausible to those who do not have the knowledge or context to challenge it, similar to a {{w|Snipe hunt}}, or several other cultural myths told about things like the {{w|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 olden days.
 
This is factually incorrect, but is plausible to those who do not have the knowledge or context to challenge it, similar to a {{w|Snipe hunt}}, or several other cultural myths told about things like the {{w|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 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 is 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.
+
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; it was common to punch holes into both 5.25" and 3.5" floppy disks to increase the storage space the computer had access to within them, rather than on punchcards where the punching several holes 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 ''[http://www.win.tue.nl/~aeb/linux/hh/thompson/trust.html Reflections on Trusting Trust]'' a famous 1984 paper by {{w|UNIX}} co-creator {{w|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.   
 
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 ''[http://www.win.tue.nl/~aeb/linux/hh/thompson/trust.html Reflections on Trusting Trust]'' a famous 1984 paper by {{w|UNIX}} co-creator {{w|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 {{w|David A. Wheeler}}'s Ph.D dissertation "[http://dwheeler.com/trusting-trust/ Fully Countering Trusting Trust through Diverse Double-Compiling (DDC)]".
+
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 {{w|David A. Wheeler}} Ph.D dissertation "[http://www.dwheeler.com/trusting-trust/ Fully Countering Trusting Trust through Diverse Double-Compiling (DDC)]".
 +
 
 +
Nine years before this comic was released [[Randall]] made a comic called [[303: Compiling]]. The next comic after this one, [[1756: I'm With Her]], was released Monday the day before the {{w|2016 United States presidential election}}. And in that comic a Cueball with a sword on an office chair like in the old compiling comic is featured. Seems realistic that Randall had that politically loaded comic ready for some time, and when finding and deciding to use that old version of Cueball, he may have gotten inspired to make this comic about compiling in the old days.
  
 
==Table of statements==
 
==Table of statements==
Line 27: Line 33:
 
|-
 
|-
 
|Compile things for different processors
 
|Compile things for different processors
|{{w|Compiler}}s convert code from a human-readable programming language into a binary code that can be directly executed by computer 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. {{w|Low-level programming language|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.
+
|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 {{w|Machine code|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.
+
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.
 
|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.
 
|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.
+
|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 will 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.  
 
|Before garbage collection, data would pile up until the computer got full and you had to throw it away.  
|A {{w|Garbage collection (computer science)|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.  
+
|A {{w|Garbage collection (computer science)|garbage collector}} is a piece of the software that cleans the {{w|RAM}} 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.  
 
|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.  
 
|-
 
|-
Line 46: Line 52:
 
|-
 
|-
 
|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 could only be written on punch cards. You had to pick a compact font, or you'd only fit a few characters per card.
|{{w|C (programming language)|C}} is a programming language. A {{w|punch card}} is a early form of storing data; the pattern of holes and non-holes in a paper or cardboard card represented information.  
+
|{{w|C (programming language)|C}} is a programming language. A {{w|punch card}} is a primitive form of storing data; it stored data in {{w|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.  
|Punch cards were used through the late 1970s and early 1980s to enter programs and data in COBOL, FORTRAN and other early languages.  Punch cards and punch card machines were being replaced by magnetic storage and {{w|text editor|text editors}} by 1972, when C (or C++) was developed.  This site demonstrates a card punch and cards: [http://www.masswerk.at/keypunch/ Keypunch].
+
|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 {{w|text editor}} long before C (or C++) was developed as a language.  This site demonstrates a card punch and cards: [http://www.masswerk.at/keypunch/ 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.)
+
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 load 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++ was big because it supported floppy disks. It still punched holes in them, but it was a start.
 
|{{w|C++ (programming language)|C++}} is a programming language. A {{w|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.
 
|{{w|C++ (programming language)|C++}} is a programming language. A {{w|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 {{w|Double-sided disk}}), or it can also be a reference to the "index hole" of 5.25" floppy disks (see {{w|Floppy_disk#Design|Floppy disk Design}}  and the tiny hole at the right of the big central hole in this [https://www.staff.ncl.ac.uk/roger.broughton/museum/floppys/images/201041b.jpg 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.
+
|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 programing 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 {{w|Double-sided disk}}), or it can also be a reference to the "index hole" of 5.25" floppy disks (see {{w|Floppy_disk#Design|Floppy disk Design}}  and the tiny hole at the right of the big central hole in this [https://www.staff.ncl.ac.uk/roger.broughton/museum/floppys/images/201041b.jpg 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.
 
|}
 
|}
  
Line 84: Line 90:
 
[[Category:Comics featuring Cueball]]
 
[[Category:Comics featuring Cueball]]
 
[[Category:Comics featuring Hairbun]]
 
[[Category:Comics featuring Hairbun]]
[[Category:Old Days]]
 
[[Category:Comics sharing name|Old Days]]
 
 
[[Category:Programming]]
 
[[Category:Programming]]

Please note that all contributions to explain xkcd may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see explain xkcd:Copyrights for details). Do not submit copyrighted work without permission!

To protect the wiki against automated edit spam, we kindly ask you to solve the following CAPTCHA:

Cancel | Editing help (opens in new window)