Editing Talk:2138: Wanna See the Code?

Jump to: navigation, search
Ambox notice.png Please sign your posts with ~~~~

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 20: Line 20:
 
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 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.
+
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.
 
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)
  

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)

Template used on this page: