Editing 1671: Arcane Bullshit

{{comic
| number    = 1671
| date      = April 22, 2016
| title     = Arcane Bullshit
| image     = arcane_bullshit.png
| titletext = Learning arcane bullshit from the 80s can break your computer, but if you're willing to wade through arcane bullshit from programmers in the 90s and 2000s, you can break everyone else's computers, too.
}}

==Explanation==
When fixing/improving an existing computer program, programmers sometimes need to read, understand, and improve old (and usually bad) code. The older a piece of code is, the less it tends to conform to modern programming practices, and the more likely it is to be "arcane bullshit" from the perspective of a 21st Century programmer.

[[Randall]] seems to feel that willingness to deal with "arcane bullshit" is a "{{w|Catch 22}}" that prevents 80s arcane bullshit from being fixed. Someone completely unwilling to deal with arcane bullshit would lack the patience to learn how to program. Someone extremely willing to wade through an 80s programmer's arcane bullshit is likely to "[[356: Nerd Sniping|nerd snipe]]" themselves into fiddling with {{w|Kernel (operating_system)|kernels}} (which are inherently arcane bullshit) instead of making useful code. Cueball is in the middle of the scale: smart and patient enough to make the 80s bullshit worse, but not smart and patient enough to know how to fix it.

This comic could 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. On the other hand, old programmers argued that calculated GOTO was a sexy way of programming.

To combat the problem computer scientists have relied on increasing the levels of abstraction and encapsulation, by developing {{w|structured programming}}, {{w|procedural programming}}, and {{w|object oriented programming|OOP (object oriented programming)}}.

In structured programming you break your program into well defined blocks of code with specified entry and exit 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 as functions or procedures, making it a lot easier to know how to call the blocks and edit them. Languages that made this a focus include Pascal, Modula, and C.

Structured and 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 so 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.

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 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 some of these in [[424: Security Holes]] (2008), [[1353: Heartbleed]] and [[1354: Heartbleed Explanation]] (2014). 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==
:[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:
:[Left end:] Low
:[Left tick:] Never learn to program
:[Above Cueball:] Me
:[Center tick:] Learn enough to break everything but not enough to fix it
:[Right end:] High
:[Right tick:] Spend all your time compiling kernels and never make anything

{{comic discussion}}
[[Category:Comics featuring Cueball]]
[[Category:Charts]]
[[Category:Programming]]