Editing 1671: Arcane Bullshit
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 8: | Line 8: | ||
==Explanation== | ==Explanation== | ||
− | + | {{incomplete|First draft. Please go over it and try to fix any mistakes.}} | |
+ | In the '80s, computer sciences in general were far out of the public eye and rapidly advancing for the niche group who did work with it. As such, programming became complex very quickly, leading to its current state of being "arcane bullshit" (understood by few; mysterious or secret). | ||
− | + | This comic could also be a reference to changes in programming methodologies. As the first computer programs were written in the 40's and 50's they were prone to becoming "spaghetti code", where the flow of execution would jump from one part of the program to another using the JUMP which gives no state information. While this method of programming can work very quickly, it makes it difficult to predict program flow and can create interdependencies that are not obvious. In the BASIC language JUMP was called GOTO and the courses for new programmers argued that using GOTO in all but trivial cases was a very bad idea. | |
− | + | To combat the problem computer scientists have relied on increasing the levels of abstraction and encapsulation, by developing Structured Programming, Procedural programming, and OOP (Object Oriented Programming). | |
− | + | In structured programming you break your program into well defined blocks of code with specified entry points. Using the stack (a portion of memory dedicated to storing information / program state) it is possible to call a block of code and then have that block of code return control to the point that called it after it has done what was requested. | |
− | + | Very quickly it was decided to mark these blocks of code out as functions or procedures, making it a lot easier to know how to call them blocks and edit them. Languages that made this a focus include Pascal, Modula, and C. | |
− | + | Structured / Procedural programming were well entrenched in the 80's. Most systems programming was done in mid or low level languages, which to improve performance don't do much to control access to the data structures in the programs. Because they are low level the code requires many steps to do seemingly easy things like draw a box on a screen. Making it hard for a non-experienced programmer to understand what is happening. | |
− | + | Although the idea of OOP was around as early as the 1950's, it was not implemented in a widespread fashion until the 1990's. OOP encapsulates the data structures inside of functions, so rather than manipulate the variable directly you call the data structure and tell it to do something. This additional level of abstraction can make it a lot easier to work on varied data. It also can protect the program data from unexpected changes by other sections of the program. | |
− | + | Because code in the 80's was typically done at a much lower level, it can be hard for programmers used to having the language and libraries do more work for them. It also meant that programmers would often hard code expectations into their source code such as the number of files that can be opened at once, or size of the operating system disk buffers, rather than make them configurable while the program is running, or even while it was being loaded. This means if you need the program to handle a larger file, you might need to recompile it after finding and changing all the places in the code that assume the smaller max file size. | |
− | + | As such, few people are willing to try to surpass the massive barrier to learning. This group is on the left. To the right are people who have gotten used to the tools and conventions of the 80's that they spend all of their time adjusting and recompiling the kernel of their computers to match their current needs, instead of actually creating new programs. | |
− | + | In the center is Cueball, presumably representing Randall, who has learned enough to try and fix code, but not enough for his fixes to actually work. | |
− | |||
− | In the center is Cueball, presumably representing Randall, who has learned enough to | ||
As programs age, they often lose support from the initial project head and die out, no longer supported on new computers. So, as the title text says, learning more coding from the '90s and after is necessary for also breaking everyone else's computers. | As programs age, they often lose support from the initial project head and die out, no longer supported on new computers. So, as the title text says, learning more coding from the '90s and after is necessary for also breaking everyone else's computers. | ||
− | This could also be a comment on hacking and the advent of the internet and the technologies behind that (TCP/IP, HTML, CSS, PHP...) being | + | This could also be a comment on hacking and the advent of the internet and the technologies behind that (TCP/IP, HTML, CSS, PHP...) being 90s/2000s. Computers in the 80s were typically stand alone so what you are learning can only be applied to your machine. To break everyone else's you need to understand networking. |
− | The title text might be a reference to various recently discovered {{w|security vulnerabilities}} in {{w|open-source software}}. In some cases, underskilled programmers have provided flawed code for critical infrastructure with very little review, resulting in global computer security disasters. Randall described | + | The title text might be a reference to various recently discovered {{w|security vulnerabilities}} in {{w|open-source software}}. In some cases, underskilled programmers have provided flawed code for critical infrastructure with very little review, resulting in global computer security disasters. Randall described one of these in [[1353: Heartbleed]] and [[1354: Heartbleed Explanation]]. Other recent examples include {{w|Shellshock (software bug)|Shellshock}} and vulnerabilities in the {{w|Linux kernel}} involving the [http://timetobleed.com/a-closer-look-at-a-recent-privilege-escalation-bug-in-linux-cve-2013-2094/ perf] and [http://perception-point.io/2016/01/14/analysis-and-exploitation-of-a-linux-kernel-vulnerability-cve-2016-0728/ keyrings] subsystems. |
==Transcript== | ==Transcript== | ||
:[A horizontal graph with arrows pointing left and right with labels. The line has three ticks one towards each end and one in the middle above which Cueball is drawn. Below each tick there is a caption. There is a caption at the top of the panel:] | :[A horizontal graph with arrows pointing left and right with labels. The line has three ticks one towards each end and one in the middle above which Cueball is drawn. Below each tick there is a caption. There is a caption at the top of the panel:] | ||
: Willingness to wade through some 80's programmer's arcane bullshit: | : Willingness to wade through some 80's programmer's arcane bullshit: | ||
− | :[Left end:] Low | + | :[Left end:] Low |
:[Left tick:] Never learn to program | :[Left tick:] Never learn to program | ||
:[Above Cueball:] Me | :[Above Cueball:] Me | ||
Line 47: | Line 46: | ||
{{comic discussion}} | {{comic discussion}} | ||
+ | |||
[[Category:Comics featuring Cueball]] | [[Category:Comics featuring Cueball]] | ||
[[Category:Charts]] | [[Category:Charts]] | ||
[[Category:Programming]] | [[Category:Programming]] |