1421: Future Self

Explain xkcd: It's 'cause you're dumb.
Revision as of 22:58, 2 February 2024 by 42.book.addict (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
Future Self
Maybe I haven't been to Iceland because I'm busy dealing with YOUR crummy code.
Title text: Maybe I haven't been to Iceland because I'm busy dealing with YOUR crummy code.


This comic is a joke about how the person you were in the past can be viewed as a distinct entity from who you are now, as well as the predictability of future events relating to your future actions.

The comic shows comments, informational notes left in the code that do not change the algorithm, from a project completed by Cueball some time ago that is still being used and maintained. It is implied that Cueball is looking at these comments because the algorithm, a parsing function, is no longer working. These comments were written by Cueball's "younger self" in anticipation of being read by his "older self" at a date close to the present. The function has held up to the younger Cueball's expectations as it has lasted until the publication date of this comic, September 2014. 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. These comments are surprisingly accurate, leading Cueball to rhetorically reply to his younger self that these comments were creepy. Cueball's "younger self" must have anticipated a snarky reply and reminded his older self that his older self has likely not fulfilled his dream of going to Iceland. Cueball again replies that his younger self should stop judging him.

In the title text, current-day Cueball lashes out at his younger self, further emphasizing the way he is viewing his past self as a different person, blaming the ineffectiveness of his past self's coding for never going to Iceland, even though the effectiveness of his past code has no correlation with being able to travel, unless he had to fix the code for a project, ruining the time space he had to travel, or his code helped him plan his trips.

A comment is a line, or a portion of a line, of code which should not be executed. A number of computer languages, including Python, use "#" to indicate "the remainder of this line is a comment". 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.

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 extract useful information from a source external to the algorithm. Often parsing functions are written using regular expressions or in some other write-only language style. Parsing can be a difficult problem to solve, and programmers will often take shortcuts (perform kludges) based on assumptions on the kinds of input that the parsing function will have to handle, or possibly code through means of trial-and-error. As the programmer may not have control over the input, such as reading a page from someone else's web-site or using the output of an unpredictable program, an input that does not match the assumed input syntax in can cause the parser to break, even if the parsing function has not changed.


[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!
comment.png add a comment! ⋅ comment.png add a topic (use sparingly)! ⋅ Icons-mini-action refresh blue.gif refresh comments!


# 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. 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? 08:19, 15 September 2014 (UTC)

(Dealing with edit conflict) Let me check what you mean. 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. 08:23, 15 September 2014 (UTC)
aaaand dodged by yet another editor 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.) 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. 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)

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. -- 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. 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). 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?" 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. (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 01:45, 22 June 2015 (UTC)
Glad to see I wasn't the only one to have this thought. It just totally clicks. 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)