1671: Arcane Bullshit - Revision history

DollarStoreBa'al: A reminder that we are supposed to be explaining the comics here. Removed the nerd sniping reference and formalized language.

2025-10-09T14:39:01Z

A reminder that we are supposed to be explaining the comics here. Removed the nerd sniping reference and formalized language.

Jacky720: rv

2022-05-04T23:48:24Z

Show changes

Ex Kay Cee Dee at 23:48, 4 May 2022

2022-05-04T23:48:20Z

Show changes

Jacky720: rv

2022-05-04T21:10:40Z

Show changes

Ex Kay Cee Dee at 21:10, 4 May 2022

2022-05-04T21:10:17Z

Show changes

Davidy22: Reverted edits by X. K. C. D. (talk) to last revision by 108.162.216.211

2022-05-04T01:45:45Z

Reverted edits by X. K. C. D. (talk) to last revision by 108.162.216.211

Show changes

X. K. C. D. at 01:20, 4 May 2022

2022-05-04T01:20:27Z

Show changes

108.162.216.211: Undo revision 235238 by X. K. C. D. (talk)

2022-05-04T00:06:43Z

Undo revision 235238 by X. K. C. D. (talk)

Show changes

X. K. C. D. at 00:01, 4 May 2022

2022-05-04T00:01:21Z

Show changes

172.70.86.22: /* Explanation */ WHOopS

2022-02-09T14:26:33Z

‎Explanation: WHOopS

@@ Line 10: / Line 10: @@
 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.
+[[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 find themselves compiling {{w|Kernel (operating_system)|kernels}} instead of making useful code. Compiling a Kernel is the act of converting human-readable source code into code which a computer can recognize and follow. Because this is a complicated process, the time it takes to do this can vary from 60 seconds to multiple hours when dealing with highly complex or sophisticated code. As such, this may prevent a programmer from making their own code as they are spending all their time compiling kernels rather than coding.
 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.

@@ Line 18: / Line 18: @@
 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 handled. Languages that made this a focus include Pascal, Modula, and C.
+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.