Difference between revisions of "1421: Future Self"
(→Explanation: Psychological projection?) |
|||
Line 18: | Line 18: | ||
The parsing function has held up to the younger Cueball's expectations as it has lasted a year past 2013 (comic published in September 2014). So he has correctly judged how external factors would affect the parsing function. | The parsing function has held up to the younger Cueball's expectations as it has lasted a year past 2013 (comic published in September 2014). So he has correctly judged how external factors would affect the parsing function. | ||
− | Current-day Cueball feels the need to rhetorically reply to his younger self's commentary, and then notices a forward-looking, mean- | + | Current-day Cueball feels the need to rhetorically reply to his younger self's commentary, and then notices a forward-looking, mean-spirited remark that is both prescient and emotionally hard-hitting. Past Cueball has the advantage that it is easy to predict that his future self might not follow through with aspirations or resolutions. But in the title-text current-day Cueball is refusing to accept any blame, preferring to blame someone else (his past self), a form of {{w|Psychological projection|projection}} that is very common human behavior. |
==Transcript== | ==Transcript== |
Revision as of 16:01, 16 September 2014
Future Self |
Title text: Maybe I haven't been to Iceland because I'm busy dealing with YOUR crummy code. |
Explanation
The comic presumably shows part of a computer software file from an old project written by Cueball. The part shown in the comic consists entirely of comments. A number of computer languages, including several popular ones, use "#" to indicate "the remainder of this line is a comment". A comment is a line, or a portion of a line, of code which should not be executed. The comment symbol tells the compiler to skip to the next line, ignoring everything after the symbol. Programmers make use of comments to leave notes about what a particular line or section of code is meant to do, places that require debugging, ideas for future revisions, etc.
These comments were written with apparent foresight by Cueball's "younger self" in anticipation of being read by his "older self" at some point in the future. The language in the comments is similar to how people address themselves in personal time capsules, in which they put letters away to read years later to see how much they've changed.
A "parse function" is code that interprets some form of input and makes sense of it in a way that enables functionality in some other part of the code. Parsers are commonly used to to extract useful information from the text of a web-page that has been "scraped" off the web, or to understand the command-line arguments of a program, or in an interpreter which runs computer code. Parsing can be a difficult problem to solve, and programmers will often take shortcuts based on assumptions on the kinds of input that the parsing function will have to handle. If the programmer does not have control over the input, such as reading a page from someone else's web-site, then any changes to the input syntax in the future can cause the parser to spontaneously break even if the parsing function has not changed. In the case of a web page, the difference may be in the structure of the page and not even visible to someone looking at the page in a web browser, or it could be the result of a "site refresh" where the look and feel of the entire web-site is changed to avoid appearing dated, or the website may no longer exist, or any number of other possible differences.
Programmers often don't spend much time looking at previously written code that is working, so the younger self has made the assumption that the parsing function, which worked at one point in time, has 'failed'. Possibly it was originally kludged together with no expectation that it would handle future changes, since the comments indicate a firm belief that the parsing function could not be easily "re-kludged" to handle the new situation but instead would need to be re-written. This may be because the parsing function was written using regular expressions or in some other write-only language style, where the program is typically created through means of trial-and-error, and it is considered easier to start from scratch than try to determine how the original program worked. Or it could be that the new situation has "mightier" inputs that can not be parsed by regular expressions, for example when a regular grammar is replaced by a context-free grammar.
The parsing function has held up to the younger Cueball's expectations as it has lasted a year past 2013 (comic published in September 2014). So he has correctly judged how external factors would affect the parsing function.
Current-day Cueball feels the need to rhetorically reply to his younger self's commentary, and then notices a forward-looking, mean-spirited remark that is both prescient and emotionally hard-hitting. Past Cueball has the advantage that it is easy to predict that his future self might not follow through with aspirations or resolutions. But in the title-text current-day Cueball is refusing to accept any blame, preferring to blame someone else (his past self), a form of projection that is very common human behavior.
Transcript
- [Cueball is sitting at a laptop, reading code. The two separate parts of code as well as the two comments by Cueball is connected with "speak" lines, with the line from the code going down to the computer screen.]
- # Dear Future Self,
- #
- # You're looking at this file because
- # the parse function finally broke.
- #
- # It's not fixable. You have to rewrite it.
- # Sincerely, Past Self
- Cueball: Dear Past Self, it's kinda creepy how you do that.
- # Also, it's probably at least
- # 2013. Did you ever take
- # that trip to Iceland?
- Cueball: Stop judging me!
Discussion
# Dear Future Editor
# As author of the first explanation, I know of what I write. Perhaps minus the snarky code-commenting.
# But I've a feeling there's a better way of writing it, and possibly a different context that I've missed.
#
# ...so over to you.141.101.99.7 08:20, 15 September 2014 (UTC)
The last paragraph was written with assumption no other content is here yet (because there wasn't) - can someone incorporate it correctly with the rest, please? 141.101.89.217 08:19, 15 September 2014 (UTC)
- (Dealing with edit conflict) Let me check what you mean. 141.101.99.7 08:20, 15 September 2014 (UTC)
- Ahah! Yes, we were both dealing with edit conflicts, only in different orders (me in here, you in the main article). I think I'm going to let a third party resolve the explanation, it'd probably be best.141.101.99.7 08:23, 15 September 2014 (UTC)
- aaaand dodged by yet another editor 108.162.249.206 08:47, 15 September 2014 (UTC)
I'm not sure I totally agree with the sentence: "The parsing function seems to have lasted one year longer than expected by the younger Cueball." Younger Cueball expected that the parsing function would fail on or after 2013, which is pretty accurate if it failed in 2014. Djbrasier (talk) 14:22, 15 September 2014 (UTC)
- "It's at least 2013" parsed to me as "this will certainly work until part-way through 2013", so the fact that the message in a bottle is uncovered in 2014 says a year longer than worst expectations. OTOH, an alternate interpretation would be "this can't fail before 2013". Maybe, just maybe, Past Cueball (and we don't know how long ago Past Cueball wrote this) is smart enough to say that, so... Who knows.
- (Also, related to what @Artyer below says, I've reconsidered my ideas about this. Maybe Past Cueball is actually just going "I wonder what it was like in Iceland?", but of course Present Cueball has a guilty conscience about this never coming to pass and takes the innocent comment badly. And I'm also seeing a lot of cynicism about Regexps... Using regexps is usually the best way to allow easy 'rekludging'. Indeed, import pattern-strings from a plain-text flatfile, branching options with and the like with sufficient power from an external flat-file and you needn't touch the code at all, just modift the associated "config file". Again, this is something I've done, for frequently permutating sources. But, even without, with access to the source code hard-coded regexps aren't necessarily the disaster.) 141.101.99.7 20:16, 15 September 2014 (UTC)
- This is almost mirroring the talk on the wikipedia page for write-only languages, but while *any* language can be written in a maintainable fashion, there are some situations where a quick result is the goal, and there are some languages/features that are amenable to that goal. The bad rap that scripting languages get for maintainability is almost certainly due more to the nature of problems that scripting languages are used to solve (and the time constraints in which they are written) than to the nature of the language itself. Finally, it's arguably better to spend a day writing a parser, then a day every year re-writing the parser because it broke, than a week writing the parser *properly*, then an hour a year updating the parser's config. Of course, YMMV. The description probably doesn't need any specific languages mentioned, but I think the reference to write-only code is relevant. 108.162.249.206 01:52, 16 September 2014 (UTC)
- agreed - "write-only" is relevant. Regex is easily as prone to being effectively write-only as JavaScript or PHP - once you can read the syntax quickly, it's far more readable and maintainable (just like JavaScript or PHP. There is nothing INHERENTLY write-only about regex -- Brettpeirce (talk) 17:35, 16 September 2014 (UTC)
- This is almost mirroring the talk on the wikipedia page for write-only languages, but while *any* language can be written in a maintainable fashion, there are some situations where a quick result is the goal, and there are some languages/features that are amenable to that goal. The bad rap that scripting languages get for maintainability is almost certainly due more to the nature of problems that scripting languages are used to solve (and the time constraints in which they are written) than to the nature of the language itself. Finally, it's arguably better to spend a day writing a parser, then a day every year re-writing the parser because it broke, than a week writing the parser *properly*, then an hour a year updating the parser's config. Of course, YMMV. The description probably doesn't need any specific languages mentioned, but I think the reference to write-only code is relevant. 108.162.249.206 01:52, 16 September 2014 (UTC)
There's nothng wrtten about the trip to Iceland that cueball was plannng to go on (procrastination caused him not to). Maybe something like "in this case, it was that cueball knew he wouldn't go on the trip he planned" but I rewrote it like 5 times, and it didn't work. —Artyer (talk) 16:45, 15 September 2014 (UTC)
I think the sentence about context free and regular grammars over-interpretates this a bit. First of all, there are many regex engines which support back-references, thus allowing more than regular grammars; second of all, a "kludged" parser very often assumes that the input is grammatically correct and just wants to extract the required information. --108.162.254.32 17:01, 15 September 2014 (UTC)
- Agreed, and as I mentioned above maybe it's worth removing mention of regular expressions at all. There's nothing in the comic to suggest that the parse function would be using a single language or feature, so there's no reason to suggest Cueball would be using regular expressions without any kind of wrapping script. 108.162.249.206 01:56, 16 September 2014 (UTC)
- There's nothing to prove any particular language, but regex uses EXACTLY that character to denote comments, is by its nature a PARSING language (whether for validation, extraction, or mutation), and is WELL KNOWN for being written with little regard to readability only to be compressed even more to a nearly-impossible-to-read-string and shoved in somewhere without the slightest context to help someone finding it to understand what the heck it is. So I would say there is "something" in the comic to suggest the use of regex. -- Brettpeirce (talk) 17:36, 16 September 2014 (UTC)
The first 'h' is backwards in the line " The parse function finally broke" 20:18, 15 September 2014 (UTC)
- It appears to be a capital-H (not technically chiral, unlike a small-h), to match the capitality of the long-standing standard of XKCD writing and the rest of the writing on this comic, but somehow obscured/over-smeared by the preceding "T". Image editing error, of some kind? Other characters' anti-aliased fringes quite happily run into their neighbours without similar artefacts. See the "TU" out of the first line's "FUTURE". On the other hand, the effect repeats in the "THAT" at the end of the "DEAR PAST SELF" text, except with a token two-pixel 'riser' remaining in this case. See also "# THAT TRIP TO ICELAND?" at the end and "THIS FILE" near the beginning. A style element?
- And to address the Incomplete-Tag's current question about the word "snark", please change it if you don't like it or know what that means (I suppose I'd say "snide and sarcastic" would be a good 'back portmanteau' explanation as to its intended usage). 141.101.99.7 20:43, 15 September 2014 (UTC)
- Alright... who's gonna start the Backmanteau wikipedia page? -- Brettpeirce (talk) 17:49, 16 September 2014 (UTC)
- The "TH" being run together may be Randall doing a manual kerning of some kind. --RenniePet (talk) 12:22, 16 September 2014 (UTC)
Does anybody else see a Walter Mitty (movie version obviously, which I thought was a great homage) reference with the trip to Iceland question? I read it as, "did you ever get a life and go out and see the world or have you spent the last X years still just coding, instead of fulfilling some dreams?" 108.162.242.18 03:33, 20 September 2014 (UTC) dgebel
There could also be an intended reference here to Ray Bradbury's short story "Night Call, Collect" in which an old man in a deserted Martian town begins receiving harassing phone calls recorded by his much younger self. 108.162.245.58 (talk) (please sign your comments with ~~~~)
- It probably isn't a reference to anything except the general concept of leaving messages for your future self (that said I was mostly reminded of Karkat from Homestuck, who spends a significant portion of his narrative having screaming matches with his past and future selves...) -Pennpenn 108.162.250.162 01:45, 22 June 2015 (UTC)
- Glad to see I wasn't the only one to have this thought. It just totally clicks. 162.158.63.166 23:19, 21 September 2019 (UTC)
print "in some languages it's '//'"
oh wait i gotta stop messing around with that one project xd An user who has no account yet (talk) 02:36, 6 September 2023 (UTC)