Discover more from Deus In Machina
Geek Mythology: The Religious, and Spiritual Folklore surrounding Programming
You've been visited by St. Ignucious. Upvote for success in FOSS
The word of the day is religionization. According to the Merriam-Webster dictionary it means…
to make religious : imbue with religious principles : bring into conformity with religious standards : interpret or understand (a thing) from a religious framework
When I first started learning how to program I was surprised at how much religious, spiritual, and folklore surrounded it. I mean this is computers! Shouldn’t it all just be rational and logical? Turns out this isn’t the case, and some people have taken this concept to the extreme building entire Operating Systems based on their faith1. Let’s look at some notable examples.
The Usenet Holy Wars ⚔️
Conceived in 1978 Usenet was the precursor to the internet. It allowed people to communicate over a distributed network of computers. Users could read and post messages on Newsgroups for a wide variety of topics. When it was first created it was only used by graduate students and academics. But as it grew in popularity more and more people used it to discuss things outside of academia, including favorite T.V shows, movies, games, and software tools. This would ultimately lead to the Usenet Holy Wars as they are now known. Emacs vs Vi/Vim, BSD vs Linux, Tabs vs Spaces, the list goes on an on2. Programmers have had their preferences since the age of computing. But beyond simple preferences, there are those who elevate their personal choices to moral imperatives3. When this happens, emotions run high, rationality gets left at the door, and ad hominem attacks become the norm. One of the most famous examples comes from our Favorite Finnish Flamer Linus Torvalds himself over Linux vs Minix4
The connection is obvious here. Humans have been fighting over belief for as long as there have been two competing religions within close proximity of each other. It’s only natural that with wide variety of software and tools that programmers would become just as passionate. My only hope is that unlike the crusades, no blood has ever been shed over someones personal choices in software.
A Koan is a Zen Buddhist story, question, or dialogue that is told to provoke a deeper understanding of a subject. Many programmers count themselves as Zen Buddhists. Whether due to the stress of Silicon Valley, or the insanity that comes from trying to speak to something as unfeeling or unforgiving as a computer, that drives them to Buddhism, I’m not sure. My first experience with Koans was with Emacs Koans5 very early on in my programming career. My favorite one is this…
In vain does the chicken cross the road; Emacs is on both sides. – Ludovic Brenta.
Programming parlance has adopted this terminology and it goes one of two ways. Like an ancient proverb as in the above example, or as a set of small problems that allow deeper understanding of a specific programming concept. This is how the ruby koans6 website works, with thirty different ruby problems designed to help you practice the test driven development methodology.
Sticking with Eastern philosophy we have websites like The Tao Of Programming7. With tongue and cheek snippets spread out over 9 “books” it gives insights into the act of programming. My favorite of which is…
The Tao gave birth to machine language. Machine language gave birth to the assembler.
The assembler gave birth to the compiler. Now there are ten thousand languages.
Each language has its purpose, however humble. Each language expresses the Yin and Yang of software. Each language has its place within the Tao.
But do not program in COBOL if you can avoid it.
This mystification of the way we interact with computers reminds me of the religious naturalism that is seen in the way many people react to the natural world. But the similarities don’t stop there. We have “Bibles” which are books that are considered authoritative on their subject. Many times they aren’t even referred to by their actual names but by their covers or who wrote them, as if the names themselves are sacred. Examples like “The Red Book” for the The OpenGL Programming Guide, “K&R” for The C Programming Language, “The Wizard book”, or “SCIP” for Structure and Interpretation of Computer Programs, and “The Dragon book” for Compilers: Principles, Techniques, and Tools. These books have had deep cultural impacts on the programmers that grew up reading them, and they are treated appropriately.
And it is not just books. The Lisp programming language has also taken on a mystical quality. Something not seen in other programming languages developed in that era. A famous XKCD comic describes the feeling.
Hardware and Software are complex, and whether you call the trust you put into compilers, and computers that run your code faith or something, else it’s hard to deny that at times they can appear magical. There was a time where computers were simple enough that one person could know the whole thing inside and out. That they could solder every component themselves and truly build everything from scratch. If you are Ben Eater you still can8. Even though computers are complex I don't think that's an excuse not to learn more about them. I attempted this on a small scale with the Raspberry PI 49, challenging myself to understand how the hardware works on it. But even the best of us's knowledge breaks down somewhere in the computer -> hardware pipeline, and we just have to take things on faith. God knows how many millions of lines of code have to be executed from the time I press a key on my keyboard, to the time the next character appears in this web browser. It's amazing that it works at all, and I'm grateful I don't need to understand all of it for it to keep working. Sometimes when I'm coding I like to think about all the things I put my faith into.
That the compiler will compile my code properly
That the Operating System will interact with my program the way I want it to
That the machine code will excite the necessary transistors to do the work in the processor I need it to do
That turning my computer on and off just fixes things sometimes
That the libraries I’m using don’t have back doors that will steal all my data
and on and on and on
I know it’s not magic, but it certainly feels like it. And there are still things like soft errors10, and a whole list of hardware errata11 that seeks to thwart your understanding. This is ontop of our varying ability to keep large chunks of programs in our head while reading code. Sometimes the code is doing something particular complex or obtuse, and even when it's actually written by a fellow human being, it’s not always clear what exactly is going on. My favorite quote about this is…
317: /* 318: * If the new process paused because it was 319: * swapped out, set the stack level to the last call 320: * to savu(u_ssav). This means that the return 321: * which is executed immediately after the call to aretu 322: * actually returns from the last routine which did 323: * the savu. 324: * 325: * You are not expected to understand this. 326: */
Line 325 is so famous, there is an entire book whose title is this quote12. Thankfully more often than not we don't need to know everything when programming. We can usually take a programming lesson from Alan Knight's quote about Object Oriented programming when working in foreign code bases.
Try not to care.
One of the great leaps in OO is to be able to answer
the question "How does this work?" with "I don’t care".
With it becoming more common for AI to write code, I fear a reality where the majority of code that is written is not by humans, and not understandable by humans. Kind of like languages that transpile to C instead of machine code first. The feeling is captured in this meme…
Finally there is a lot of folklore surrounding programming. There is literally a website called folklore13 which documents the stories of the development of the original Macintosh, and spins yarns of programming aptitude I will never reach. My favorite probably being the -2000 Lines Of Code14 story. If you are blessed enough to be immortalized in one those stories you become one of the gods in the programming pantheon. Eric Raymond describes a few in his Why Python?15 blog post.
Larry Wall, its creator, is rightly considered one of the most important leaders in the Open Source community, and often ranks third behind Linus Torvalds and Richard Stallman in the current pantheon of hacker demigods.
Not everyone agrees to who belongs in the pantheon, but for them there are fictional hackers, like Mel “The Realest Programmer of them All”16. Mel the programmer who chose not to have faith in compilers, and hand optimized all of his own code. Mel whose mastery of bit fiddling allowed him to achieve performance not though possible on any hardware he touched. Even today's elite programmers would bow at the feet of Mel's accomplishments. Go read the story it's definitely worth it.
Wrapping it all up 🎁
Programming is suffused with religious mysticism. Like the West African griots, we tell the stories of our history through metaphor, parables, and folklore. We ask our machine learning models questions like they are the Oracle of Delphi17. We take our actual faith and ask What would Jesus do? if he were programming.18 We borrow terms like Daemon, we have Chief “Evangelists”19 who spread the good word about our programming languages and software.
One thing is clear to me, there is a lot more humanity in the field of programming than people like to let on. Our Geek Mythology is still being written, and it inspires us, makes us laugh, and motivates us to achieve greater heights in the field. As I wrap up this article I’d like to leave you with one more quote. It’s from Proverbs 16:3…
the LordGitHub whatever you do, and your plans will succeed."
Call To Action 📣
If you made it this far thanks for reading! I’m still new here and trying to find my voice. If you liked this article please consider liking and subscribing. And if you haven’t why not check out another article of mine!