Difference between revisions of "Talk:2138: Wanna See the Code?"

Explain xkcd: It's 'cause you're dumb.
Jump to: navigation, search
(Title text)
(Title text)
Line 15: Line 15:
 
I tried to come up with an explanation for the title text, but honestly, that has me a bit stumped too. I'm really not sure what Randall was going for in this comic. My understanding of "downstream" is from source control software like {{w|Git}}; a developer who pulls code from a repository is said to be "downstream" of it - ie. they're receiving code. When they push their changes back, they push it "upstream".
 
I tried to come up with an explanation for the title text, but honestly, that has me a bit stumped too. I'm really not sure what Randall was going for in this comic. My understanding of "downstream" is from source control software like {{w|Git}}; a developer who pulls code from a repository is said to be "downstream" of it - ie. they're receiving code. When they push their changes back, they push it "upstream".
  
Well, "downstream" and "upstream" in git terminology rather refers to the concept of forking. A forked repository generated by github has per default the origin "upstream" set to the original repository. This term extends beyond simple git inheritance of repositories. But already with git repositories, it is obvious: put Cueballs hack into a submodule of an aspiring and fast-moving project. Someone burning the midnight oil gets tired and wants to get home, and the third corner case of Cueballs brainchild does not let him. Instead of biting the bullet, they just make more hacks, access some internal attribute or whatnot. The next guy comes along, and just copy-pastes that dirty code.
+
Well, "downstream" and "upstream" in git terminology rather refers to the concept of forking. A forked repository generated by github has per default the remote named "upstream" set to the original repository. This term extends beyond simple git inheritance of repositories. But already with git repositories, it is obvious: put Cueballs hack into a submodule of an aspiring and fast-moving project. Someone burning the midnight oil gets tired and wants to get home, and the third corner case of Cueballs brainchild does not let him. Instead of biting the bullet, they just make more hacks, access some internal attribute or whatnot. The next guy comes along, and just copy-pastes that dirty code.
 
That said, software proliferates across distributions, across operating systems, across programming languages (if there is for example an interface involved that is (kinda) language agnostic. Take REST apis for example). The reason is, a software construct always defines (an) interface(s) to which hopefully docs with preconditions, postconditions, and a reasonable correspondence to common sense are established. Well, for ad hoc software like Cueballs script, that would of course not be the case, and this goes in weaker form for e.g. many packages in official debian repositories, and their specializations (Realtime gentoo, Media Ubuntu or whathaveya). They re-package software, and where it comes from, that's upstream. Developers in that environment get accustomed to a good interface that works 90% of the times, and make software that caters to specific quirks, workarounds, etc. these workarounds will inform other interfaces in related packages, implementations. This is of course just technical debt all over again, but distributed, not in one company or something.--[[Special:Contributions/162.158.88.14|162.158.88.14]] 22:37, 17 April 2019 (UTC)
 
That said, software proliferates across distributions, across operating systems, across programming languages (if there is for example an interface involved that is (kinda) language agnostic. Take REST apis for example). The reason is, a software construct always defines (an) interface(s) to which hopefully docs with preconditions, postconditions, and a reasonable correspondence to common sense are established. Well, for ad hoc software like Cueballs script, that would of course not be the case, and this goes in weaker form for e.g. many packages in official debian repositories, and their specializations (Realtime gentoo, Media Ubuntu or whathaveya). They re-package software, and where it comes from, that's upstream. Developers in that environment get accustomed to a good interface that works 90% of the times, and make software that caters to specific quirks, workarounds, etc. these workarounds will inform other interfaces in related packages, implementations. This is of course just technical debt all over again, but distributed, not in one company or something.--[[Special:Contributions/162.158.88.14|162.158.88.14]] 22:37, 17 April 2019 (UTC)
  

Revision as of 22:49, 17 April 2019


I'm puzzled by the "they" in this: " And because you're lucky that the people around you understand that they create more problems than they solve." I take the "they"s to be the people around him, but it almost makes some sense if it was " And because you're lucky that the people around you understand that it[code,dead body] create[s] more problems than they solve." but that's not right either. Afbach (talk)

I'm puzzled by the "And because". What's that doing there? What is the 'and' connecting? 162.158.111.169 18:37, 17 April 2019 (UTC)

Pony tail is saying "[Cueball] is lucky that the people around [cueball] understand that [dead bodies] create more problems than they solve" insinuating that otherwise cueballs fate for writing such bad code would be dire. 162.158.107.25 18:52, 17 April 2019 (UTC)

I'm glad I'm not the only one struggling with the dialogue in this comic. I'm certain Randall's made a mistake. Hawthorn (talk) 20:17, 17 April 2019 (UTC)

Another take on Ponytails final comment - Queball: "My code is sort of similar to a dead body, [...]" Pontytail: "and [it is also similar to a dead body] because" everyone knows Queball writing code causes more problems than the code solves, just like creating dead bodies cause more problems than what it solves. With the title text referring to what happens with either Queballs code or dead bodies if left ignored. He is lucky, in that people realize they can't ignore his code, and have to deal with it for him before things go sideways. 162.158.106.102 20:29, 17 April 2019 (UTC)

Title text

I tried to come up with an explanation for the title text, but honestly, that has me a bit stumped too. I'm really not sure what Randall was going for in this comic. My understanding of "downstream" is from source control software like Git; a developer who pulls code from a repository is said to be "downstream" of it - ie. they're receiving code. When they push their changes back, they push it "upstream".

Well, "downstream" and "upstream" in git terminology rather refers to the concept of forking. A forked repository generated by github has per default the remote named "upstream" set to the original repository. This term extends beyond simple git inheritance of repositories. But already with git repositories, it is obvious: put Cueballs hack into a submodule of an aspiring and fast-moving project. Someone burning the midnight oil gets tired and wants to get home, and the third corner case of Cueballs brainchild does not let him. Instead of biting the bullet, they just make more hacks, access some internal attribute or whatnot. The next guy comes along, and just copy-pastes that dirty code. That said, software proliferates across distributions, across operating systems, across programming languages (if there is for example an interface involved that is (kinda) language agnostic. Take REST apis for example). The reason is, a software construct always defines (an) interface(s) to which hopefully docs with preconditions, postconditions, and a reasonable correspondence to common sense are established. Well, for ad hoc software like Cueballs script, that would of course not be the case, and this goes in weaker form for e.g. many packages in official debian repositories, and their specializations (Realtime gentoo, Media Ubuntu or whathaveya). They re-package software, and where it comes from, that's upstream. Developers in that environment get accustomed to a good interface that works 90% of the times, and make software that caters to specific quirks, workarounds, etc. these workarounds will inform other interfaces in related packages, implementations. This is of course just technical debt all over again, but distributed, not in one company or something.--162.158.88.14 22:37, 17 April 2019 (UTC)


I think what this means in context is that Cueball pushes his bad code to a repository, and other developers pull it downstream, thus "contaminating" their local environments. But honestly, this interpretation doesn't really feel satisfying to me, so I'm not sure. Hawthorn (talk) 21:25, 17 April 2019 (UTC)

The 2nd interpretation of "downstream" is downstream of a river - a dead body will contaminate the river even if it is not "touched". I think downstream for software development could just mean work for people in the future. 108.162.215.160 21:41, 17 April 2019 (UTC)