Talk:1671: Arcane Bullshit

2016-04-22T15:50:42Z

Digital night:

I was obsessively refreshing XKCD and the new comic popped up. Then I did the same on ExplainXKCD to make an explanation. Here's my first rough-draft attempt. [[User:Papayaman1000|Papayaman1000]] ([[User talk:Papayaman1000|talk]]) 13:34, 22 April 2016 (UTC)

Your explanation confuses OOP with [https://en.wikipedia.org/wiki/Structured_programming structured programming].
[[User:Svorkoetter|Svorkoetter]] ([[User talk:Svorkoetter|talk]]) 15:03, 22 April 2016 (UTC)

Developing a kernel is not the same as compiling a kernel. You would, for example, rebuild a Linux kernel after you've added a module, or changed some parameters. Also, the purpose of object-oriented programming is not to solve the problem of spaghetti code. (That problem was solved by structured programming.) It's to enforce principles of abstraction, information hiding and modularity.
[[User:Krishnanp|Krishnanp]] ([[User talk:Krishnanp|talk]]) 15:20, 22 April 2016 (UTC)

I modified the explanation on OOP to include Structured & Procedural language code and briefly described the 80's era of low level languages.
[[User:Digital_Night|Digital_Night]] ([[User talk:Digital_Night|talk]]) 15:41, 22 April 2016 (UTC)

OK, I rewrote the kernel compiling explanation to explain why someone would recompile a 80's era kernel. Modular kernels sure are nice!
[[User:Digital night|Digital night]] ([[User talk:Digital night|talk]]) 15:50, 22 April 2016 (UTC)

1671: Arcane Bullshit

2016-04-22T15:47:57Z

Digital night: /* Explanation */

{{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==
{{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 programing 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 programing 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 Programing, Procedural programing, and OOP (Object Oriented Programming).

In structured programing 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 programing were well entrenched in the 80's. Most systems programing 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 adjusting the 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.

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 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==
[A horizontal graph with three positions]
:[Graph Title] Willingness to wade through some 80's programmer's arcane bullshit
:[Left end of graph] Low / Never learn to program
:[Center of graph, with picture of Cueball] Me / Learn enough to break everything but not enough to fix it
:[Right end of graph] High / Spend all your time compiling kernels and never make anything

{{comic discussion}}

Talk:1671: Arcane Bullshit

2016-04-22T15:41:00Z

Digital night:

explain xkcd - User contributions [en]

Talk:1671: Arcane Bullshit

1671: Arcane Bullshit

Talk:1671: Arcane Bullshit