Editing 2347: Dependency

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 13: Line 13:
  
 
===Background and Examples===
 
===Background and Examples===
Taking code re-usability and modularization to its logical extreme has been a long-time tenet for programmers; programming began as a slow task on very memory-constrained systems, utilizing punch cards and days of delay waiting to discover a bug, so that reuse made things possible that otherwise wouldn't be.  Once systems became small, fast, and able to hold a lot of data, the ability to provide higher and higher degrees of automation made reusable libraries a huge engine behind the development of technology.  By outsourcing what would seem like basic functions, such as string manipulation, to other libraries, developers waste less time reinventing the wheel, so the philosophy goes (or as Beret Guy's business practices literally: [[2140: Reinvent the Wheel]]), and thus many tiny packages, many of which contained only one function, became popular dependencies. This was especially true in Unix and Linux, where an entire program is commonly used for one small task, and programs exist to tie others together into powerful shell scripts.
+
Taking code re-usability and modularization to its logical extreme has been a long-time tenet for programmers; programming began as a slow task on very memory-constrained systems, utilizing punch cards and days of delay waiting to discover a bug, so that reuse made things possible that otherwise wouldn't be.  Once systems became small, fast, and able to hold a lot of data, the ability to provide higher and higher degrees of automation made reusable libraries a huge engine behind the development of technology.  By outsourcing what would seem like basic functions, such as string manipulation, to other libraries, developers waste less time reinventing the wheel, so the philosophy goes, and thus many tiny packages, many of which contained only one function, became popular dependencies. This was especially true in Unix and Linux, where an entire program is commonly used for one small task, and programs exist to tie others together into powerful shell scripts.
  
 
Node.js (a platform for JavaScript) and Python are two modern ecosystems providing huge stashes of centralized libraries where developers of the world can come together to stand on the shoulders of all the small useful libraries they make for each other, to make new ones that are more and more powerful, and also more and more prone to sudden new unexpected bugs somewhere in the dependency chain.  JavaScript was designed to be an easy to use front end scripting language, not a basic and core backend language as users of node.js's {{w|npm (software)|NPM}} package manager have made it be.  While in theory, such a system may sound good for developers who would need to write and maintain fewer lines of code, systems which are highly optimized are also highly susceptible to rapid changes. For example, the famous left-pad incident in the NPM package manager left many major and minor web services which depended on it unable to build. [https://www.theregister.com/2016/03/23/npm_left_pad_chaos/ A disgruntled developer unpublishing 11 lines of code was able to break everybody's build, because everyone was using it.]
 
Node.js (a platform for JavaScript) and Python are two modern ecosystems providing huge stashes of centralized libraries where developers of the world can come together to stand on the shoulders of all the small useful libraries they make for each other, to make new ones that are more and more powerful, and also more and more prone to sudden new unexpected bugs somewhere in the dependency chain.  JavaScript was designed to be an easy to use front end scripting language, not a basic and core backend language as users of node.js's {{w|npm (software)|NPM}} package manager have made it be.  While in theory, such a system may sound good for developers who would need to write and maintain fewer lines of code, systems which are highly optimized are also highly susceptible to rapid changes. For example, the famous left-pad incident in the NPM package manager left many major and minor web services which depended on it unable to build. [https://www.theregister.com/2016/03/23/npm_left_pad_chaos/ A disgruntled developer unpublishing 11 lines of code was able to break everybody's build, because everyone was using it.]

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)