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 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 and exit points. By the use of a stack (a portion of memory dedicated to sequentially storing and retrieving contextual information and program state as blocks call other blocks, before returning), it is possible to call a block of code and then have that block of code return control (and any new information) 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 trivial for the compiler to know how to call and process the blocks, and make it easier for the user to edit them without having to keep track of the minutae of how they are handled. Languages that made this a focus include Pascal, Modula, and C.

Structured and procedural programming were well entrenched in the '80s. Most systems programming was done in mid- or low-level languages, which improves performance by giving the knowledgable programmer explicit control of the data structures in the programs rather than shrouding it in abstraction. But because they are at a lower level the code requires many explicit steps to do seemingly easy things like draw a box on a screen, making it easy for a non-experienced programmer to introduce errors and harder to understand what needs to be happening (ultimately, the flipping of specific bits within the graphical RAM), compared to a high-level command to just "draw a box" with given qualities and have the system work out how exactly that needs to be done.

Although the idea of OOP was around as early as the 1950s, it was not implemented in a widespread fashion until the 1990s. OOP encapsulates the data structures inside of functions, so rather than manipulate any variable directly you call the data structure and tell it to do something to (or with) its elements. This additional level of abstraction can make it a lot easier to work on varied data, if implemented with the correct handlers. It also can protect the program data from unexpected changes by other sections of the program, as most elements are restricted to being changed by the encapsulating code and transfer of information must be implemented in even higher levels of program management.

Because code in the '80s was typically done at a much lower level, it can be hard for programmers used to having the language and libraries silently do much of the 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 the size of the operating system disk buffers. 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. For graphical output, rather than direct access to a predictably constant configuration of video-RAM, now the extent of the graphics (e.g. size of the 'screen'-array, bit-depth of each pixel, even the endianness of the data) should be discovered as the program loads, or even dynamically configurable while the program is running; such as when the program's GUI window is resized by the user, changing the available 'virtual screen' canvas.

As such, few people are willing to try to surpass the massive barrier to learning how to wrangle the very detailed old code. This group is on the left. To the right are people who have gotten so used to the tools and conventions of the '80s 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 change how the code operates but not enough for his changes to be produce a working fix for whatever emerging issue he might be trying to solve.

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 be in the position of (mis)understanding networking code.

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]]