DEV Community: Diego Crespo

The Story of Nel

Diego Crespo — Fri, 29 Nov 2024 03:18:36 +0000

Happy 🦃 Day! I hope everyone has a wonderful day

Real Programmers code in the terminal.

Maybe they dabble in slick IDEs now, in this decadent era of AI assistants, auto completion, and "intelligent" debuggers. But back in the good old days, when the term "cloud" referred to the weather and not where you stored your code, Real Programmers wrote in plain text editors. Not Visual Studio Code. Not even Helix or Fleet. Just GNU Emacs and Screen.

Lest a whole new generation of developers grow up in ignorance of this glorious past, I feel duty bound to describe, as best I can through the generation gap, how a Real Programmer writes code. I'll call her Nel, because that's her name.

I first met Nel when I joined a startup aiming to disrupt the world with yet another social app. The team was young, vibrant, and glued to their screens, eyes darting between Stack Overflow tabs and AI generated code snippets. Then there was Nel, a quiet figure hunched over a terminal window, typing furiously.

Nel didn't approve of AI assistants.

"If a programmer can't write code without an autocomplete," she said, "what good are they?"

Nel had written, using nothing but Emacs and her wits, the most critical module our company had. The real time data processor that kept everything running smoothly. It was a marvel. While the rest of us wrestled with dependency hell and cursed the day JavaScript was invented, Nel's code hummed along with these things called static types that, she said, were all the documentation she needed.

One day, disaster struck. An outage in us-east-1 left us disconnected from our beloved cloud services. Panic ensued. Without Stack Overflow, AI help, or even our code repositories, we were paralyzed. Features needed fixing, bugs needed squashing, and deadlines loomed ominously.

All except Nel were in despair.

"How can we code without the internet?" someone wailed.

"I've reached my 2-hour monthly in office quota anyway. Message me on Microsoft Teams when everything is back up," said another.

Nel looked up from her terminal, a faint smile playing on her lips.

"Maybe we can, you know, stay here and write code," she suggested.

"Without documentation? Without Google? Impossible!"

Nel shrugged and returned to her screen. Curiosity got the better of me, and I wandered over to see what she was doing. Lines of code scrolled past at an impossible speed. Functions, classes, even the occasional comment, all appearing as if by magic. She wasn't even using a mouse or trackpad.

"Are you... writing a new feature?" I asked, incredulous.

"Fixing the data parser," she replied without looking up.

"From memory?"

She nodded.

"But how do you remember the syntax? The APIs? Don't you need to look up anything?"

Nel chuckled softly. "I've been coding in this language longer than most of you have been alive. Muscle memory, I suppose."

I watched in awe as she deftly wrote a for loop, complete with iterator variables and proper scope handling, all without a single reference. It was as if I'd witnessed a unicorn.

"Could you help me with a for loop?" I asked sheepishly.

She paused and turned to face me fully for the first time.

"Sure," she said, gesturing for me to sit. "What are you trying to do?"

I explained the problem, expecting her to whip out her phone to search for an answer. Instead, she grabbed a notepad and sketched out the logic, walking me through each step.

"See? No need for the internet. Just think through the problem," she said.

She laughed as I gawked.

"I used to have to do stuff like this on whiteboards for interviews," She smiled while shaking her head.

Word spread through the office. One by one, team members approached Nel, seeking guidance. She became an impromptu mentor, her desk a shrine to the lost art of independent thinking.

Meanwhile, the managers were in a frenzy. Deadlines were at risk! Productivity was plummeting! They called an emergency all hands.

"We need solutions, people!" the CTO barked. "How can we work without our tools?"

Nel stood up.

"Perhaps we've become too reliant on them," she said calmly. "Maybe it's time we trusted our own abilities."

Silence fell. The idea was radical, almost heretical.

"But how will we manage without AI suggestions? Without code linters? Without..."

"By programming," Nel reiterated, "by understanding our code, not just piecing together fragments from the internet."

An idea sparked in Nel. "We could deploy the app on premises", "Mark has a 64-core 7.5GHz laptop with 256GB of Ram and two 10TB NVME drives. If we turned off all of the startup and electron apps we'd be able to run the entire thing locally."

Eyes turned to Mark, who nodded slowly. "It just might be possible. We have as many employees here as we have users so it would be a good test of the app"

The CTO considered this. "Can we set it up quickly?"

"Absolutely," Nel interjected. "It might even run better than in the cloud."

Emboldened, we set up the on premise deployment. With Nel's guidance, the process was smooth. We bypassed the cloud entirely, running everything locally.

Her words stirred something in us. Emboldened, we returned to our desks. The hum of conversation was replaced by the clatter of keyboards. Slowly, code began to take shape...not copied, not generated, but crafted. Whenever we had issues, we would physically walk over and discuss them with our teammates. Questions that would be left unread for hours before a response was finally given, were answered in a matter of seconds.

By the time the internet was restored, it had been 6 hours, the most I've ever worked without distractedly scrolling through short form video. We had accomplished more in those disconnected hours than we had in months.

The CTO called another all hands, praising the team's resilience. They gushed about how much VC money we would be able to raise from all the featuers we had developed. But we knew who deserved the real credit.

Nel's approach had sparked a revival of genius level programming. Developers started challenging themselves to code without immediately resorting to Google. Pair programming sessions became the norm, fostering collaboration and learning. People even began reading manuals. Not everyone could hack it though, but they eventually found their way into middle management positions.

I asked Nel one day why she preferred Emacs over the myriad of sophisticated tools available.

"Because it does exactly what I need...no more, no less," she replied. "It's just me and the code."

I haven't kept in touch with Nel since she moved on to greener pastures...or perhaps terminals. But I like to think she's out there somewhere, still coding in Emacs, still eschewing the trappings of modern development.

In any event, I was impressed enough that I've started relying less on AI assistants and more on my own understanding. And while I may never reach Nel's level of mastery, I still use VS Code after all, I did download the Vim Emulation plugin. I think I might do a lunch and learn once I finally master hjkl.

For those who don’t know this is a parody of The brilliant Story of Mel if you’ve never read it I highly recommend it!

Call To Action 📣

Hi 👋 my name is Diego Crespo and I like to talk about technology, niche programming languages, and AI. I have a Twitter and a Mastodon, if you’d like to follow me on other social media platforms. If you liked the article, consider checking out my Substack. And if you haven’t why not check out another article of mine listed below! Thank you for reading and giving me a little of your valuable time. A.M.D.G

Coding without braces: An alternate C Syntax

Diego Crespo — Thu, 10 Oct 2024 13:24:25 +0000

I recently stumbled upon an interesting piece of C language trivia that underscores how different computers were when C was first created. Specifically, C allows the use of digraphs (two letter combinations that represent a single letter) like <% and %> as alternatives of { and } and <: and :> as substitutes for [ and ]. The purpose of this was to provide an alternate syntax to support keyboards and character sets where braces and brackets were not available. The Gnu C Language manual mentions these digraphs as well as %: as an alternative to #. Since nothing on the internet can be trusted anymore I wrote a simple program and compiled it to verify the claims.

#include <stdio.h>

int main() <%
    printf("Hello, World!\n");
    int array<:5:> = <%1, 2, 3, 4, 5%>; 
    for (int i = 0; i < 5; i++) <%
        printf("%d\n", array<:i:>); 
    %>
    return 0;
%>

And lo and behold (don't take my word for it) it worked! While it's hard to imagine a keyboard without these symbols today, and I might be showing my ignorance of international keyboards here, I'm glad someone thought to include these alternatives.

But if the cpp reference is anything to go by there is is an expecation that all keyboards must have ?,< and ) as there is an even more verbose version of this behavior in the form of trigraphs, which allow a three character sequence alternative instead of two. Examples include ??< for { and ??) for ] but there are many more which can be viewed in the cpp reference. While tripgrahs appear to be going away in C23, I have no doubt people have abused these as well as digraphs in code obfuscation competitions.

Call To Action 📣

Hi 👋 my name is Diego Crespo and I like to talk about technology, niche programming languages, and AI. I have a Twitter a Mastodon, and Threads if you’d like to follow me on other social media platforms. If you liked the article, consider checking out my Substack. And if you haven’t why not check out another article of mine listed below! Thank you for reading and giving me a little of your valuable time. A.M.D.G

Learning to use Docker

Diego Crespo — Thu, 21 Mar 2024 12:53:12 +0000

Docker was released 13 years ago and has quickly become a mainstay in the programming community. At first I avoided it, considering it too complex, intimidating, and a waste of time for small projects. But Docker is not any of those things. Sure, wrapping a complex project with a Docker bowtie can be challenging, but that's because non trivial projects usually require non trivial solutions. The benefits you get once this is accomplished though, is immense. But before we get to that, let's start simple. What is Docker?

Docker is a technology that helps you package and run your software applications in a consistent and efficient way, regardless of the computing environment they're running on.

This package is typically called a Docker Image. The running instance of an Image is called a Docker Container. You can think of a Docker Image like a programming language and technology agnostic version of a C# or Java project, or a Python virtual environment. In those examples, the language settings and all of the packages that you install are only for that specific project/language you are working on.

If others want to collaborate on the project, they will need to have the same settings and packages as you. For example, if you have a Python virtual environment you can run pip freeze > requirements.txt to get the list of packages your project needs, then pass along the txt file to someone else who can then run pip install -r requirements.txt to download the same packages. But what if the person trying to install the dependencies for your project has a different version of Python than you? They may run into dependency issues, due to functions being deprecated, or behavior being changed as a library matures. Docker avoids this problem.

But there are more than just dependency conflicts that can doom a project. Sometimes projects require more than what the standard library, or 3rd party package ecosystem can provide.

Let’s say you want to do OCR on some pdfs. You might decide to use pytesseract. In the installation instructions it says that you need Google Tesseract OCR, as pytesseract is a wrapper over it.

Install Google Tesseract OCR (additional info how to install the engine on Linux, Mac OSX and Windows). You must be able to invoke the tesseract command as tesseract. If this isn’t the case, for example because tesseract isn’t in your PATH, you will have to change the “tesseract_cmd” variable pytesseract.pytesseract.tesseract_cmd. Under Debian/Ubuntu you can use the package tesseract-ocr. For Mac OS users. please install homebrew package tesseract.

Unfortunately Tesseract can't be pip installed, so getting it set up can be tricky. I can't count how many times I've joined a project, and my initial experience looks like this

Try to install additional dependencies
Run into an error preventing the install
Message Teams Chat, “Hey, has anyone run into this error when installing X?”
"Oh yea, the link they give in the documentation is to an old version of X, this Stack Overflow post has the correct link"
*Continues trying to install and runs into problem Y*
Ask in the chat again
"Oh it’s because your using version ZZZ for this, you have to downgrade it because Y is expecting a version QQQ instead."

Eventually you get it all working, and go on your merry way. 3 months later, it is summer and you have new interns. One of them has been assigned to this project to help. All of a sudden you see a Teams message in chat from the new intern.

“Hey has anyone run into this error when installing X?”
You: *Thinks very hard*. "Oh I remember this error! Hold on I have a link to a Stack Overflow post that has the fix"

Repeat steps 4-7 as your intern struggles with the same issues you had 3 months ago.

If only there was some way you could construct your software applications, that would allow it to behave in a consistent and efficient way, regardless of the computer environment it's running on. Wait! What's that I hear you say? There is? Why yes! Docker of course!

Docker In Practice

Let’s use our previous example for a simple Python app that performs ocr, and prints out the text to the screen.

The following code takes a trimmed pdf from the Autobiography of Benjamin Franklin pages 7-17, and prints it out to the console.



import pytesseract
from pdf2image import convert_from_path

pdf_file = "trimmed_autobiography.pdf"

# Convert PDF pages to images
pages = convert_from_path(pdf_file, 300)  # DPI set to 300

# OCR each page and extract text
text = ""
for page in pages:
text += pytesseract.image_to_string(page)

print(text)

Now let’s look at the Dockerfile we need to build this.



FROM python:3.12-slim-bookworm

# Set the working directory
WORKDIR /app

# Install Tesseract OCR, poppler-utils, and their dependencies
RUN apt-get update && \
apt-get install -y tesseract-ocr poppler-utils && \
apt-get clean

# Install python packages
RUN pip3 install --no-cache-dir pytesseract pdf2image

# Copy the main.py and PDF file into the Docker image
COPY main.py trimmed_autobiography.pdf /app/

# Command to run the Python script
CMD ["python3", "main.py"]

Here's a break down each line of this Dockerfile:

FROM python:3.12-slim-bookworm: This line specifies the base Image to use for building the Docker Image. In this case, we are using an Image named python with the tag 3.12-slim-bookworm, which means it's based on Python 3.12 and the Debian 'slim' variant. Slim is a smaller version of Debian without extra packages. We use the Python version of Debian instead of the normal Debian Image due to the fact that regular Debian disallows global pip installs (this is normally a good thing).
WORKDIR /app: This line sets the working directory inside the Docker container to /app. It's common practice to put the code for a project in /app but your working directory can be anywhere you want. The folder will be created if it isn’t there already. Subsequent commands will be executed from inside this directory
RUN apt-get update &&:
1. RUN Is a Docker instruction that executes commands in the container during the build process.
2. apt-get update Uses the Debian Advanced Package Manager (Apt) to update the package lists for packages that are available for installation.
3. && Allows for multiple commands to be run in a single RUN instruction and the \ allows the instruction to continue onto the next line.
4. apt-get install -y tesseract-ocr poppler-utils &&: This line installs the packages tesseract-ocr and poppler-utils along with their dependencies using the apt-get install command. The -y flag automatically confirms any prompts during installation.
5. apt-get clean: This command removes any unnecessary files and packages that were downloaded during the installation process. It helps to keep the Docker image size smaller.
RUN pip3 install --no-cache-dir pytesseract pdf2image: This command installs Python packages pytesseract and pdf2image using pip. The --no-cache-dir option disables caching of downloaded packages and metadata.
COPY main.py trimmed_autobiography.pdf /app/: This line copies files main.py and trimmed_autobiography.pdf from the host machine into the /app directory within the Docker container.
CMD ["python3", "main.py"]: This is the default command to run when the container starts. It specifies to run the main.py Python script using the python3 interpreter.

A Dockerfile is kind of like as a script you would run if you wanted to automate setting up a new laptop. It would specify all the tools and their dependencies you would need and then go and fetch and install them.

Building the Docker Image

Now that we have a Dockerfile we can use it to make a Docker Image. If you open your terminal and run docker build -t book-slim . with this Dockerfile in the current directory, Docker will build a Docker Image based on the instructions provided in the Dockerfile.
Once the image is created, you can run the Docker Image with the command docker run --name book-slim-container book-slim. This executes your docker Image named book-slim and gives the running container the name book-slim-container. This is helpful because all running Images need a name. If you don’t provide one than docker will make up a name.

Looking at my Docker Desktop app, I can see that when I executed my Docker Image the first couple of times without specifying a name, Docker gave it the name “trusting_nightingale”, and “nostalgic_shaw”. But when I specified a --name, that was the name it gave my container instead.

Getting back to our running program, after waiting patiently you should start seeing text printed out to the screen

My father had also, by the same wife, four
children born in America, and ten others by
a second wife, making in all seventeen. I
remember to have seen thirteen seated to-
gether at his table, who all arrived at years
of maturity, and were married. I wus the
last of the sons, and the youngest chiid, ex-
cepting two daughters. I was born at Bos-
ton, in New England. My mother, the sec-
ond wife, was Abiah Folger, daughter of
Peter Folger, one of the first colonists of
New England, of whom Cotton Mather makes .
honorable mention, in his Ecclesiastical His-

So, we built our Docker Image which specified all the dependencies we need to run the program, then we ran our Image, and it executed the main.py to print the pdf's text to the terminal like we asked it to. Run the command in the terminal again, but be warned it will fail.

docker run --name book-slim-container book-slim

This is the error message you will get



docker: Error response from daemon: Conflict. The container name "/book-slim-container" is already in use by container "5bf83a1f62e4e6191fd502b889282334a1e666b42f473ed43e3d61fc87ac013c". You have to remove (or rename) that container to be able to reuse that name.
See 'docker run --help'.

The reason for this is that Docker requires each container to have a unique name, and we already created one named book-slim-container

To resolve this, we have a few options...

Remove the existing container: You can remove the existing container with the conflicting name using the docker rm command.



docker rm book-slim-container
or
docker rm 5bf83a1f62e4e6191fd502b889282334a1e666b42f473ed43e3d61fc87ac013c

Rename the existing container: If you want to keep the existing container but use a different name for the new one, you can rename the existing container using the docker rename command

docker rename book-slim-container new-name

Restart and re-execute the container: An existing container can be restarted, and then re-executed.

docker restart book-slim-container && docker exec book-slim-container python3 main.py

Avoid the issue altogether: Because an already created Docker Image is easy to execute as a container, it is common to pass the parameters --rm to delete the container after it is run, so subsequent runs can just recreate themselves using the same container name and Image

docker run --rm --name book-slim-contaner book-slim

Exploring containers

Let’s peel back the veil a bit on the container itself. Run the following command in the terminal.

docker run --name book-slim-container -it book-slim /bin/bash

Here’s what these new commands do

-i: Stands for "interactive mode". This means that the container's standard input will remain open even if not attached
-t: Stands for "tty" or "pseudo-terminal". It allocates a pseudo-terminal for the container
Together, -it ensures that the container session is interactive, allowing you to interact with the shell running inside the container */bin/bash: Overrides the default command specified in the Dockerfile (python3 main.py) and starts a bash shell (/bin/bash) inside the container.

If the interactive command ran successfully, you should be inside the container in the WORKDIR /app.

If you type ls you can see the two files that were copied into the container when the Docker Image was built. You can do python --version and see that the python version is 3.12 and run the main.py file manually. It all works like you would expect. When you are done exploring the container you can type exit in the terminal.

So the advantage of this approach is that you do all the hard work of figuring out all the dependencies for a project, and then encode that into a Dockerfile. Then your coworkers, friends, or collaborators just need to have Docker installed, and then they can run two simple commands to get up and running with your project



docker build -t  book-slim .
docker run --rm --name book-slim-contaner book-slim

Mounting volumes

Let’s make our python program more useful. Instead of printing out the text from the pdf, let’s save it to a file. Here is the new main.py



import pytesseract
from pdf2image import convert_from_path

pdf_file = "trimmed_autobiography.pdf"

# Convert PDF pages to images
pages = convert_from_path(pdf_file, 300)  # DPI set to 300

# OCR each page and extract text
text = ""
for page in pages:
text += pytesseract.image_to_string(page)

output_file = "extracted_text.txt"

with open(output_file, "w", encoding="utf-8") as file:
   file.write(text)

print("Text extracted and written to:", output_file)

If we were to run the Docker Image now with

docker run --rm --name book-slim-container book-slim

The extracted_text.txt would not be written in the same directory you ran the Docker Image. It would write inside the container, and then get cleaned up once the container finishes running. To make the written file accessible outside of the container, you want to mount a directory using the -v command.

Mounting a host directory into a Docker container allows you to share files and directories between the host machine (where Docker is running) and the container. When you mount a directory, you're essentially creating a link between a directory on your host system and a directory inside the container. This has 3 advantages

Access to Host Files: Any files or directories in the mounted directory on the host machine are accessible from within the container.
Persistence of Data: Changes made to files or directories in the mounted directory from within the container persist on the host machine, and vice versa. This means that if a file is created, modified, or deleted in the mounted directory from either the host or the container, the change will be reflected in both places.
Sharing Resources: Mounting a directory can be useful for sharing resources such as code, configuration files, or data between the host and the container. This is particularly handy during development or when you need to provide input data or retrieve output data from a container.

Here is the full command to replicate this behavior.

docker run --rm --name book-slim-container -v .:/app book-slim

To make sure the file is written locally, I pass .:/app to the -v command. This mounts the current directory ‘.’ on the host machine to the /app directory inside the container.

After a few moments, extracted_text.txt appears, confirming that I successfully wrote the file to disk

And that's the basics of Docker. There are still many other aspects of Docker worth getting into (Docker-Compose, managing multiple docker containers, exposing ports, etc) but this should at least get you started. In the mean time, I hope that this article made Docker more approachable, and I hope you use it in one of your next projects!

Call To Action 📣

The DOIT philosophy: How I'm avoiding Decision Fatigue and the Paralysis of Choice

Diego Crespo — Thu, 21 Mar 2024 12:48:45 +0000

My mantra for this year is DOIT and it stands for

DO
Overcome
Iterate
Triumph

I have a lot of projects that are in various states of completion, and I want to get them over the finish line. I just need to DOIT. In service of this, another goal of mine in 2024 is simplicity. By focusing on simplicity I will be able to more effectively achieve my project goals. Einstein's famous quote is applicable here

It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience

Amusingly, the more familiar version of this quote is actually a simplified version of the former. It illustrates the point well...

Everything should be made as simple as possible, but no simpler

The key is the 2nd part of the quote "but no simpler". Complexity is the bane of Programmers, and I've been making my life more complicated than it has to be recently. Sure, there are things that are complex just by their very nature, and just like how I wouldn't fear 1 duck, but 100,000 would give me pause, a 100,000 line code base would still be challenging to work with no matter what the language. But at least languages that value simplicity leave more space in your brain for the actual code part, so you don't end up looking like this

Or as Andrew Kelly puts it with Zig

Focus on debugging your application rather than debugging your programming language knowledge.

Ultimately what we are trying to do as Programmers is create things, and complexity gets in the way of that. But the complexity which has inhibited my ability to complete projects doens't just stop at what programming languages I am using, there are other things that cause complexity, and they result in two things. Decision fatigue and the Paralysis of Choice. Let's get a baseline for how these are defined

Decision Fatigue: The deteriorating quality of decisions made by an individual after a long session of decision making. Essentially, the more decisions you make, the more your ability to make further decisions diminishes. This is because making decisions is cognitively taxing, and over time, the mental resources needed to weigh choices, foresee outcomes, and make judgments become depleted. As a result, an individual might resort to simpler decision-making strategies, exhibit reduced self control, or even avoid making decisions altogether as they become fatigued.
Paralysis of Choice: When an individual is faced with too many options and finds it difficult to make a decision. Instead of making a choice, the person becomes overwhelmed by the options available and may feel anxious or unable to choose at all. The paralysis of choice suggests that having too many options can lead to less satisfaction with the eventual choice made, due to the stress of the selection process and the potential for regret over the alternatives not chosen.

How it affects people

The important thing to note about the two definitions above is that it doesn't say anything about a specific scenario where this happens. It is simply the act of decision making, and the number of choices that cause the problems. This is why successful people employ the trick of wearing the same close to reduce the amount of decisions they make. But while this is definitely not a live like a "billionaire" grindset sort of article, the principles are sound. CEOs simplify their lives so they can make big decisions that steer the direction of companies and billions of dollars in capital. But we can do the same thing to be more successful in achieving more goals.

How it affects me

To this end I've tried to simply many aspects of my life. One way I've done this is cutting down to one large monitor. This might seem controversial as the productivity gain from two is almost double a single monitor. But a second monitor also invites temptation. It's easy to put things on that 2nd screen that are just for entertainment and don't serve the current task at hand. Furthermore, I find the little snags that come with a 2nd monitor interrupt my flow when I'm working on things. For example

Windows opening on the wrong screen
Windows opening between two screens
Resolution issues when both monitors are not the same size
Deciding which monitor a window should be on

The point is not that these things can't be fixed, it's that they require three things of mine that are in limited supply. My concentration, my decision making energy, and my will power to not watch YouTube videos. I would rather alt tab to another window when I really need it, or split my window in two so I can read the documentation. Plus with one monitor I don't have to worry about one screen being in a suboptimal position. Everything is always comfortably in my vision.

Another way I am simplifying my life is to stick to one operating system. I would switch distributions multiple times a year, as the sheen of the new one faded. This required me to spend a better part of the day just setting up everything again, and then another month running into things I had to set up because I used them so infrequently. This year I'm forcing myself to stick with Pop!_OS as my main desktop's operating system. Pop!_OS is good, so this isn't the hardest decision, but speaking it into existence as opposed to privately muttering it to my self provides some accountability.

I'm also cutting down on the number of programming languages I will start new projects in. I've been hopping programming languages like I hop distributions, and while I've appreciated the breadth of experience this has given me, I find that it has caused me to have very shallow experience in a lot of languages that aren't Python. Furthermore, a lot of my projects start with me just digging into what programming language I'm going to use, what libraries are available for the task, and how to make my code more idiomatic. I find myself trying to Goldilocks myself into the right programming for the project, but it never works. This paralysis of choice has a subtle but deadly side effect that I have been feeling more frequently too

leading to less satisfaction with the eventual choice made, due to the stress of the selection process and the potential for regret over the alternatives not chosen.

Less satisfaction and regret, two things I don't need more of in my life. Along these same lines I will reduce the number of categories these projects fall under. From GUI to Games, Programming Language Theory to Machine Learning, and Art to Level Design, I've doing a lot of things that cover a lot of different topics. They are all interesting, and I wish I could spend all every waking moment hoping between them, but I will never reach the level of proficiency I want to be at if I spread myself so thin.

Finally as programmers there are tons of decisions we have to make related to...

Programming languages
Frameworks
Windows vs Mac vs Linux
Mechanical Keyboard Switches
frameworks
Wall Paper Color
Text Editor Font
Text Editor
ECS, Functional, OOP
Web, Mobile Desktop

Before we've even written a single line of code. It's no wonder so many of us want to start a farm instead. But I'm saying let's not throw the baby out with the bath water. Maybe I can pare things down a bit and focus on actually putting code to text editor. And if I don't pick the perfect stack for my project, who cares, just deal with it. My programming ancestors did more with less. Now I'm not saying to scale your product to millions of users using just Google Sheets, but it's hard to go wrong with a mainstream language today.

Of course, I will still learn new things for my job, and I will still write about the interesting things I do here. But I will cut back in places that I can. As it currently stands I have over a years worth of drafts saved up, so even if I just draw inspiration from my drafts it will cover me well into 2025. But, as the year is not even close to over, I suspect I'll come across more little nuggets that will spark ideas for new articles. In the mean time, I hope to get some projects completed as well.

Call To Action 📣

A World Without C

Diego Crespo — Thu, 07 Mar 2024 13:02:56 +0000

The Whitehouse released a report this week encouraging the use of memory safe languages, over non memory safe languages, specifically calling out C/C++. This has obviously caused a stir in the programming community, especially considering most people's low opinion of the government’s ability to produce quality software. But if you’ve used a computer in the last year you’ve probably been subjected to poor quality software made by the brightest minds in Silicon Valley, so it's a moot point

Missing Points

What I find surprising in all of this discourse is that people have missed the point, intentionally or not. Memory unsafe languages have footguns that lead to unsafe software, and that leads to CVEs that cause harm to real people. The context for the report is not your hobby project, nor your single player 2D platformer. It’s about software that power governments and institutions, places that store large amounts of people’s data etc. It’s about companies that provide live services to millions of people, and store their credit card numbers, phone numbers, addresses, names, and dates of birth. This also not about it becoming illegal to program in memory unsafe languages. To sum it up

Programmers writing lines of code do not do so without consequence; the way they do their work is of critical importance to the national interest.

The Enduring Legacy of C

A lot of the discourse revolves around C, with the main point being that you will never get rid of it. That the world runs on C, your operating system runs on C, your programming language runs on C etc, etc. I know how important C is, I've written multiple articles that feature C prominently, and I'll probably write some more

There are a lot of reasons for C's dominance in the modern era, but the one that sticks out to me is that it is the lowest common denominator for just about everything. If you write something in C, it is straightforward in most languages to bind to it through an FFI. That means if I for instance, come across a cool C library that does exactly what I need, I can just bind the functions in my Python code without knowing all the nitty gritty details of how it's implemented. I can do it again in Go, and Java and C# and on and on. Just look at the list of programming languages that have Raylib bindings to see how powerful of a concept this can be

C's Simplicity and Its Challenges

But Cs greatest strength is also its greatest weakness. It's simple. My 2nd Edition of K&R is just shy of 300 pages, but a good chunk of that is a reference manual, and a chapter on lexical conventions which can be skipped on a first read through. You could skim through the book in a day. But while the syntax may be simple, there are a lot of concepts in C that are tricky to get right, especially in large programs

Pointer Arithmetic
Memory Management
Headers/Preprocessor
Macros
Undefined Behavior
Strings and Cross Platform string behavior/support
Actually building large projects

And you don't have to take my word, here is C++ being brought up again as an alternative to C in the Linux Kernel just this year (2024), by someone who has programmed more C than I ever will in my lifetime. And here is a page that details GCC's transition to C++ (the irony is not lost on me). If these people are the best C programmers in the world, what chance do I have? Even John Carmack talks about being surprised in the Lex Fridman podcast about how many mistakes he found when he attacked his code base with sanitizers and fuzzing.

You might ask, well can't we just make C a better language? And the answer is yes, but that takes time. I'm really looking forward to many of the changes that are in C23, but it will be many years before that will be widely available across MSVC, Clang, and GCC. And getting any feature into C is an exercise in frustration. You only have to read JeanHeyd Meneide's article titled Finally, Embed in C23 to understand how thankless of a task this is. I'll give you one excerpt, but I've seen this same sentiment time and time again when it comes to improving the language

It’s deeply depressing and ultimately a great source of burnout being at the grindstone for 4 years for things people were casually discussing about in September of 1995 (and earlier). It’s almost as depressing as putting typeof in the C Standard and then realizing this was something they’d been discussing doing since after C89 (1989). Am I destined to just keep closing the loop on old, unrealized dreams because a bunch of people were too tired/scared/busy/combative to standardize what has literally been decades of existing practice?
It was hard to realize how tired I was of this kind of grind until the day the feature was put into the C Standard, this past Tuesday. I quite literally could not even muster a “yes!” after the vote finished. I just felt empty and numb, because quite literally dragging an entire community of implementers through several hurdles, to finally get them to acknowledge the existence of a problem and its solution, is just… soul-crushing. It is a level of effort that I recommend to nobody in any sphere of life, for any task. At least when you are on the ground and organizing and helping people, you’re providing some kind of material value. Water. Food. Improving something. Here? I’m talking about things that are quite literally older than I am. Just trying to bring ideas from the last 3 decades - things you would think were Table Stakes for foundational languages like C and C++ languages - would not be seen as a radical new paradigm or shift in the language. Nevertheless, I spent (burned?) that energy, and finally. It's in.

That doesn't sound like a fun process to me...

Now if you're still here I want to make it clear that there are qualities of C that I admire. It's an important language in the annals of programming history, and it is well worth learning. I love C's Spartan nature when I'm practicing Algorithms and Data Structures, and I appreciate that it produces software that is small and fast. Today's modern programming languages have done a shit job at filling in the C's shoes, which is why it's still around so prominently. I think of all the programming languages out there, Zig is the one I'm most hopeful for replacing C in what C does best. And it does so while being safer, easier to cross compile and build, and without adding a ton of complexity to the syntax like languages like Rust, D, and C++ do. Now to my main point...

Envisioning a Post C World

It is worth noting that C didn't appear on the scene until 1972. That means that 60% of the population in the United States has been around longer, and there are plenty of programmers that remember a world where C didn't exist. C was also absent in the early 8-Bit era compared to programming languages like Basic, Pascal, and Assembly due to its difficulty to compile. So really it's only like 45 years that C has been a major player in the programming space. But people keep repeating the same mantra over and over again "C will never die", which feels like a shocking amount of small mindedness coming from the programming community. I thought we were supposed to be innovative thinkers, problem solvers, and engineers. Must we forever be shackled to a programming language we created 50 years ago, in field that is only 75 years old? Is it really not possible to envision a world that isn’t powered by C or C++ even if it takes another 50-100 years?

Two Years ago no one was talking about Large Language Models. We were still 30 years away from anything remotely resembling a useful AI assistant. Now, one year later my Church is using AI Generated images from ChatGPT in their service, and Nvidia has doubled its stock priced in a year. 8 Years ago Visual Studio Code was released, and now it is the most popular text editor by far. The programming space can move quickly if the value is there, and I believe that moving away from C is one of those things. If our best years of programming are still to come (and I hope they are), and we expect more code to be written in the next few years than at any other point in history, then the percentage of C code should dwindle every year. If the financial incentives are there, and if governments will start biasing favor towards more memory safe languages, then there will be a strong incentive for certain companies to comply.

Replacing C does not mean erasing its legacy. I will continue to write about C, and tell its part in the ever evolving history of programming, and I hope you will continue to enjoy the story as it is written.

Call To Action

Experimenting with GUIs on the Pi Zero

Diego Crespo — Sat, 02 Mar 2024 23:18:56 +0000

I recently brought an old Raspberry Pi Zero back to life. With the oldest files dating back to the summer of 2020, it was safe to say that it was time for a fresh install. Thankfully there is still a version of Raspberry Pi OS that supports 32 bit Raspberry Pi's like the Zero W

It comes with Bookworm which is a recent Debian release, which means we get nice goodies like Python 3.11, version 6+ of the Linux kernel (up from 4.19 in the old install), and newer versions of lots of other software. Not that I'll be using the RPI Zero much like a Desktop. A 32-bit single core CPU clocked at 1 Ghz, with 512Mb of RAM, is basically abandonware at this point as a Desktop platform. Even the default installer from the Raspberry Pi foundation installs software you can't use. It asks whether you want to install Chromium and or Firefox, but both programs say this when you try to use them

Chromium/Firefox is not supported on the Raspberry PI Zero W

Whether it's actually realistic to use the Raspberry Pi Zero as a Desktop is a boring question. Who cares! It's fun. But anyway, I'm more interested in using the Zero W to test the baseline performance of some apps that I'm writing anyways, so this isn't a problem. Let's start by looking at a couple of programs on the Pi Zero and see how they perform out of the box. The answer... Pretty slow, but not as bad as I was expecting. Opening up basic software like the terminal, and the file browser take anywhere from 3-6 seconds. That's definitely slow, but even on my beefy desktop with an SSD, most of the apps I use take at least 1-3 seconds to start up. That's not even an order of magnitude faster on a machine that is much more powerful. But complaining about software performance in 2024 is so passé so I'll just say it sucks. It did pique my interest in performing some highly unscientific testing though which is what you will get below.

Being nerdsniped by timing random apps opening, I decided to write some basic GUI apps that did nothing more than open an 800x600 window, and time them on my phone. Starting off with GTK, I modified the basic GTK4 tutorial example

#include <gtk/gtk.h>

static void
activate (GtkApplication* app,
          gpointer        user_data)
{
  GtkWidget *window;

  window = gtk_application_window_new (app);
  gtk_window_set_title (GTK_WINDOW (window), "Window");
  gtk_window_set_default_size (GTK_WINDOW (window), 800, 600);
  gtk_window_present (GTK_WINDOW (window));
}

int
main (int    argc,
      char **argv)
{
  GtkApplication *app;
  int status;

  app = gtk_application_new ("org.gtk.example", G_APPLICATION_DEFAULT_FLAGS);
  g_signal_connect (app, "activate", G_CALLBACK (activate), NULL);
  status = g_application_run (G_APPLICATION (app), argc, argv);
  g_object_unref (app);

  return status;
}

Compiling the tutorial with the -O2 optimization set, I was astonished to see the app take between 12-14 seconds to open a blank window. Now GTK4 does a lot for us out of the box, and that comes with an upfront cost. But for a blank window that is pretty bad. I looked around for some examples of deploying apps on resource constrained systems with GTK, and even asked in the GNOME forums but couldn't find any solutions. If you know of any please let me know.

With that shocking result, I decided to get a baseline for how fast a window could open up. I did this by making as simple X application that opens a window, and then timing the result...

#include <X11/Xlib.h>
#include <stdio.h>
#include <stdlib.h> // For exit function

int main() {
    Display *display;
    Window window;
    XEvent event;
    int screen;

    // Open connection to the X server
    display = XOpenDisplay(NULL);
    if (display == NULL) {
        fprintf(stderr, "Cannot open display\n");
        exit(1);
    }

    screen = DefaultScreen(display);


    window = XCreateSimpleWindow(display, RootWindow(display, screen), 10, 10, 800, 600, 1,
                                 BlackPixel(display, screen), WhitePixel(display, screen));


    XSelectInput(display, window, ExposureMask | KeyPressMask);


    XMapWindow(display, window);


    while (1) {
        XNextEvent(display, &event);

        // Break out of the loop if the user presses any key
        if (event.type == KeyPress)
            break;
    }


    XCloseDisplay(display);
    return 0;
}

Except, I almost didn't have a chance to time the result, as the window opened up in ~0.5 seconds. I'll be the first to tell you this is not an Apples to Apples comparison, and writing a GUI using just X11 would be an exercise in suffering. (I mean but that's basically what Casey Muratori did in his Handmade Hero Series for Windows). But if all apps opened at that speed, my RPI Zero W wouldn't feel slow at all. Armed with this new knowledge, I decided to look at a couple of other ways of opening a window.

Since I've been on an SDL2 kick recently, it only made sense to do the same test with that library. You make recognize this code as essentially the example I wrote in SDL Tutorial Part 1: Opening A Window from a couple weeks ago

#include <SDL2/SDL.h>
#include <stdio.h>
#include <stdlib.h>

#define SCREEN_WIDTH 800
#define SCREEN_HEIGHT 600

int main(){
  if (SDL_Init(SDL_INIT_VIDEO) < 0){
    printf("Couldn't initialize SDL: %s\n", SDL_GetError());
    return EXIT_FAILURE;
  }

  SDL_Window *window = SDL_CreateWindow("Example: 0", SDL_WINDOWPOS_UNDEFINED,
                    SDL_WINDOWPOS_UNDEFINED, SCREEN_WIDTH, SCREEN_HEIGHT, 0);
  if (!window){
    printf("Failed to open %d x %d window: %s\n", SCREEN_WIDTH, SCREEN_HEIGHT, SDL_GetError());
    return EXIT_FAILURE;
  }

  SDL_Renderer *renderer = SDL_CreateRenderer(window, -1, 0);
  SDL_SetRenderDrawColor(renderer, 255, 255, 255, 250);
  SDL_RenderClear(renderer);
  SDL_RenderPresent(renderer);
  SDL_Delay(2000);
  SDL_DestroyWindow(window);
  SDL_DestroyRenderer(renderer);
  SDL_Quit();
  return EXIT_SUCCESS;
}

And our results... A little over 3.1 seconds. While SDL2 is not a retained mode GUI, I could certainly do more with it than I could with just a raw X app. So, so long as people didn't need a screen reader for the program, this might be a viable option. (I'm not even sure you could run any sufficiently complex app, and a screen reader on the RPI Zero, at the same time anyway though).

I recently made a simple GUI app in Python with Tkinter, and since it's already built into Python I wrote my example in it next to see how it would perform

import tkinter as tk

app = tk.Tk()
app.title("Simple 800x600 Window")

app.geometry("800x600")

app.mainloop()

~2.9 seconds. For an language that has to interpret the code upfront, that is not bad. I think that Tkinter is an underrated gem of the Python world, and I'll be writing more about that soon. But, while the Tk integration with Python is great, I wanted to look at two more implementations. One using the de facto Tcl bindings to Tk, and the other using just raw C and Tk

#!/usr/bin/env wish

wm title . "Simple Window"
wm geometry . 800x600

tkwait window .

Tcl is an interesting language that warrants its own discussion at a later date, but on my RPI Zero I was able to open up the window in ~2.0 seconds which is a great improvement. Considering we are entering the territory of as fast, or faster than the default apps, I feel like we have reached acceptable speeds. But Python and Tcl are just binding the underlying C Tk library, so let's look at C next.

#include <tk.h>

int main(int argc, char **argv) {
    Tcl_Interp *interp;
    Tk_Window window;

    // Initialize Tcl and the Tk toolkit
    Tcl_FindExecutable(argv[0]);
    interp = Tcl_CreateInterp();

    if (Tcl_Init(interp) == TCL_ERROR) {
        return -1;
    }

    if (Tk_Init(interp) == TCL_ERROR) {
        return -1;
    }

    // Create a new top-level Tk window
    window = Tk_MainWindow(interp);

    // Set the title of the window using Tcl command
    Tcl_Eval(interp, "wm title . \"Simple Tk C App\"");

    // Set the size of the window
    Tk_GeometryRequest(window, 800, 600);

    // Start the Tk event loop
    Tk_MainLoop();

    return 0;
}

Honestly maybe a tenth of a second faster than Tcl example but much less ergonomic. I did compile everything with -O2 when I could, but I think that is just a testament to how well Tcl and Tk are integrated.

Next I looked at the Fast Light Toolkit (FLTK), a cross platform GUI library I used many years ago when I first attempted to learn C++. Fun fact this is also the GUI library used to create the Eureka Doom Level editor, a cross platform tool I have extensive experience with.

It's certainly got the right name for this test, so let's see if it can live up to it.

#include <FL/Fl.H>
#include <FL/Fl_Window.H>

int main() {
    // Create a window with dimensions 800x600
    Fl_Window *window = new Fl_Window(800, 600);

    // Set the window label
    window->label("My FLTK Window");

    // Show the window
    window->show();

    // Run the FLTK event loop
    return Fl::run();
}

Aaand at 1.1 seconds we have a new winner. That was really impressive. I would be curious to see how much of it's speed it could retain with a more complex application.

To finish this test off, I'll add two late additions. A simple Qt6 app using QT Widgets and C++

#include <QApplication>
#include <QWidget>

int main(int argc, char *argv[])
{
    QApplication app(argc, argv);

    QWidget window;
    window.resize(800, 600);
    window.setWindowTitle("Simple Qt6 App on Raspberry Pi Zero");
    window.show();

    return app.exec();
}

and a QtQuick example with qml

import QtQuick 2.15
import QtQuick.Window 2.15

Window {
    width: 800
    height: 600
    visible: true
}

Compiling these apps made my little Pi Zero chug, but it was worth it. At a little under 2.5 seconds for QT widgets, and 2.75 seconds for the QML example, that's not bad. QT is used a lot in the auto industry for infotainment systems which are not known for their specs, so it's not surprising that we could get something running on our RPI Zero. Qt also comes with all the same goodies that GTK and other fully featured cross platform GUIs would need to build any type of app, so its performance here indicates it would be pretty snappy on any computer more powerful than a Raspberry Pi Zero. It's not my favorite cross platform GUI for a few reasons, but every non electron based desktop GUI developer job I've seen uses it, so that's a strong point in its favor.

Now, I'll be the first one to tell you that there are a lot more that goes into making a GUI app than how fast it opens. There is the set of widgets that it provides, how cross platform it is, what its memory footprint looks, its ability to provide a native "look and feel" etc. All things we didn't test here. But I hope that I've at least convinced you to give one of these great libraries a try

Call To Action 📣

SDL Tutorial in C Part 2: Displaying Text

Diego Crespo — Fri, 23 Feb 2024 00:20:22 +0000

This is part 2 of my SDL series using C. If you missed part 1 you can find it here.📌

Displaying Text Cheat Sheet

Tutorial

Displaying Text in SDL2 requires a very similar set of operations to how we handled creating a window and renderer in part 1. But before we get to displaying text, we need to include the appropriate header. Since SDL2 is designed to be modular, the libraries that work with text are in their own separate headers/files. To work with text, you will need SDL_ttf.h. You can either include it and the appropriate files directly in your project, linking them at compile time, or if you are on Linux like I am, use your package manager to install them globally. While we won’t be going over the specifics for how to set up SDL in this tutorial, the SDL Wiki provides a page on how to properly set up SDL that is pretty thorough. Now, for those of you who just want to see the code, here is the entire source



#include <SDL2/SDL.h>
#include <SDL2/SDL_ttf.h>
#include <stdio.h>
#include <stdlib.h>

#define SCREEN_WIDTH 1280
#define SCREEN_HEIGHT 720
#define MY_FONT "/usr/share/fonts/truetype/freefont/FreeSans.ttf"

int main(){
  if (SDL_Init(SDL_INIT_VIDEO) < 0){
    printf("Couldn't initialize SDL: %s\n", SDL_GetError());
    return EXIT_FAILURE;
  }
    // Initialize SDL_ttf
    if (TTF_Init() < 0) {
        printf("SDL_ttf could not initialize! TTF_Error: %s\n", TTF_GetError());
        SDL_Quit();
        return EXIT_FAILURE;
    }

  SDL_Window *window = SDL_CreateWindow("Drawing Text", SDL_WINDOWPOS_UNDEFINED,
                    SDL_WINDOWPOS_UNDEFINED, SCREEN_WIDTH, SCREEN_HEIGHT, 0);

  if (!window){
    printf("Failed to open %d x %d window: %s\n", SCREEN_WIDTH, SCREEN_HEIGHT, SDL_GetError());
    return EXIT_FAILURE;
  }

  SDL_Renderer *renderer = SDL_CreateRenderer(window, -1, 0);

  if (!renderer){
    printf("Failed to create renderer: %s\n", SDL_GetError());
    return EXIT_FAILURE;
  }

  SDL_SetRenderDrawColor(renderer, 255,255,255,255);
  SDL_RenderClear(renderer);

  TTF_Font *font = TTF_OpenFont(MY_FONT, 64); // specify the path to your font file and font size

  if (!font){
    printf("Failed to load font: %s\n", TTF_GetError());
    return EXIT_FAILURE;
  }

  // Create surface with rendered text
  SDL_Color textColor = {0, 0, 0, 255}; // black color
  SDL_Surface *textSurface = TTF_RenderText_Solid(font, "Hello World!", textColor);

  if (!textSurface) {
    printf("Failed to create text surface: %s\n", TTF_GetError());
    return EXIT_FAILURE;
  }

  // Create texture from surface
  SDL_Texture *textTexture = SDL_CreateTextureFromSurface(renderer, textSurface);

  if (!textTexture){
    printf("Failed to create text texture: %s\n", SDL_GetError());
    return EXIT_FAILURE;
  }

  // Render text
  SDL_Rect textRect = {50, 50, textSurface->w, textSurface->h}; // rectangle where the text is drawn 
  SDL_RenderCopy(renderer, textTexture, NULL, &textRect);

  SDL_RenderPresent(renderer);
  SDL_Delay(2000);
  SDL_DestroyWindow(window);
  SDL_DestroyRenderer(renderer);
  SDL_Quit();

  return EXIT_SUCCESS;
}

Starting off we #include <SDL2/SDL_ttf.h> which gives us access to functions that help us display text. Since the ttf module works with fonts, which are normally, .ttf files, we need a font to properly display the text in our Window. You can either download a font from the internet, or use a .ttf file that you have on your computer. To keep it simple, I’ll just use one of the default ones that comes on my computer. At the top of my program, I've created a define that simply points to a default font



 #define MY_FONT "/usr/share/fonts/truetype/freefont/FreeSans.ttf"

On macOS you should be able to find some .ttf files located at /Library/Fonts and on Windows C:\Windows\Fonts

Following the same paradigm we used to initialize our SDL video module, we have to initialize our ttf library. The same pattern is used, where we check to see if the return value of the TTF_Init function is less than zero, and if it is, we display an error to the user



    // Initialize SDL_ttf
    if (TTF_Init() < 0) {
        printf("SDL_ttf could not initialize! TTF_Error: %s\n", TTF_GetError());
        SDL_Quit();
        return EXIT_FAILURE;
    }

If the ttf library was installed and linked correctly then we can attempt to load a font using TTF_OpenFont. Again we want to check that the font was actually loaded and we do that with our if statement



  TTF_Font *font = TTF_OpenFont(MY_FONT, 64); // specify the path to your font file and font size

  if (!font){
    printf("Failed to load font: %s\n", TTF_GetError());
    return EXIT_FAILURE;
  }

Now that we've loaded our font we need to create a text surface using TTF_RenderText_Solid This surface is essentially an image containing the rendered text. Since this is an operation that can fail, we want to make sure that we check this using an if statement like we've done before



 // Create surface with rendered text
  SDL_Color textColor = {0, 0, 0, 255}; // black color
  SDL_Surface *textSurface = TTF_RenderText_Solid(font, "Hello World!", textColor);

  if (!textSurface) {
    printf("Failed to create text surface: %s\n", TTF_GetError());
    return EXIT_FAILURE;
  }

The next step uses SDL_CreateTextureFromSurface to convert our SDL_Surface (your rendered text) into an SDL_Texture. This is necessary because modern SDL2 uses the GPU for rendering, and textures are the GPU-friendly way of handling images. This conversion process uploads the surface data to the GPU memory, enabling efficient rendering. This operation can also fail, so it is important to check that it doesn't before doing anything with the texture



  // Create texture from surface
  SDL_Texture *textTexture = SDL_CreateTextureFromSurface(renderer, textSurface);

  if (!textTexture){
    printf("Failed to create text texture: %s\n", SDL_GetError());
    return EXIT_FAILURE;
  }

Finally, we call SDL_RenderCopy. This function call tells SDL2 to copy the text texture to the renderer. The SDL_Rect textRect that is defined is used to position and size the text on the screen.

It is important to understand that nothing will be drawn on the screen yet. It's more like preparing what needs to be drawn. The actual drawing happens when you call SDL_RenderPresent



  // Render text
  SDL_Rect textRect = {50, 50, textSurface->w, textSurface->h}; // rectangle where the text is drawn 
  SDL_RenderCopy(renderer, textTexture, NULL, &textRect);

If all goes well then when you run the code, you should see some text on the screen. With that, you are well on your way to learning the core components of using the SDL2 library. With just the information that you’ve learned from part 1 and part 2, you should be able to make a graphical version of the guess my number game, a common beginner programming task, but with a SDL flavored twist. You could even create a text adventure, if you were so inclined.

One final note. Between this and the last tutorial, you may be seeing a lot of repetitive code that might be better off abstracted away in functions. That’s good, and means you are getting familiar with the patterns in the library. Opinions about the structure of code should be based off the needs of the code base. While I’m keeping it simple for these tutorials, eventually we should abstract away some common patterns.

FAQ

Why Not Draw Directly to the Renderer?

SDL2 uses two main types of objects for drawing: SDL_Surface and SDL_Texture. SDL_Surface is a CPU-based bitmap, useful for manipulating pixel data directly. SDL_Texture, on the other hand, is GPU-based. Modern SDL2 applications use the GPU for rendering (via SDL_Renderer), which is faster and more efficient but requires textures, not surfaces.

The reason you can't directly render the font to the renderer is that SDL2_ttf is designed to work with surfaces, as historically SDL handled rendering with surfaces before textures and GPU rendering were introduced.

Does that mean that SDL2 can render just the surface instead of the texture if I don't want to use the GPU?

Yes, SDL2 can render using just an SDL_Surface without converting it to an SDL_Texture if you prefer or need to render without using the GPU. This approach is known as "software rendering" and it's done entirely by the CPU, bypassing the GPU.

Software rendering with SDL_Surface was the primary method used in SDL before SDL2 introduced hardware-accelerated rendering with SDL_Texture and SDL_Renderer. While software rendering is less efficient and slower than hardware accelerated rendering, it can be useful in certain scenarios, like on systems with limited or no GPU capabilities. Instead of using a renderer like we are using you would instead create a SDL_Surface with SDL_GetWindowSurface



SDL_Surface *windowSurface = SDL_GetWindowSurface(window);

Call To Action 📣

SDL Tutorial Part 1: Opening A Window

Diego Crespo — Sat, 17 Feb 2024 16:45:22 +0000

I was recently learning SDL2, and I found the lack of tutorials in plain C frustrating. I've decided to be the change I wanted to see in the world, and write my own. This will be a multi-part series, and will serve as a quick reference for how to do common things in SDL2. I've listed the main functions at the top of the tutorial kind of like the Raylib Cheatsheet, if you just need a quick reference.

Before we dive in, I want to point out an immensely helpful resource that will be useful as you become more experienced. The SDL2 Wiki contains an index which has a link to every SDL function wiki page. This will teach you everything you need to know about calling the function and handling its output properly. If a big list of functions is too disjointed, there is also a wikipage that links to the same resources, but organized into API categories as well. This can be useful as common operations usually require multiple functions that are related.

Open a Window Cheat Sheet

Tutorial

The simplest and fastest way to get a window open in SDL2 is to write the following code.

#include <SDL2/SDL.h>
#include <stdio.h>
#include <stdlib.h>

#define SCREEN_WIDTH 1280
#define SCREEN_HEIGHT 720

int main() {
    SDL_Window *window = SDL_CreateWindow("Example: 0", SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, SCREEN_WIDTH, SCREEN_HEIGHT, 0);
    SDL_Renderer *renderer = SDL_CreateRenderer(window, -1, 0);
    SDL_SetRenderDrawColor(renderer, 255,255,255,250);
    SDL_RenderClear(renderer);
    SDL_RenderPresent(renderer);
    SDL_Delay(2000);
    SDL_DestroyWindow(window);
    SDL_DestroyRenderer(renderer);
    SDL_Quit();
    return EXIT_SUCCESS;
}

But this is not recommended. It's possible that many of the functions that we just called can fail, so we want to include a few more checks to make sure that everything is working correctly. Let's do that now

int main(){
  if (SDL_Init(SDL_INIT_VIDEO) < 0){
    printf("Couldn't initialize SDL: %s\n", SDL_GetError());
    return EXIT_FAILURE;
  }

  SDL_Window *window = SDL_CreateWindow("Example: 0", SDL_WINDOWPOS_UNDEFINED,
                    SDL_WINDOWPOS_UNDEFINED, SCREEN_WIDTH, SCREEN_HEIGHT, 0);
  if (!window){
    printf("Failed to open %d x %d window: %s\n", SCREEN_WIDTH, SCREEN_HEIGHT, SDL_GetError());
    return EXIT_FAILURE;
  }

  SDL_Renderer *renderer = SDL_CreateRenderer(window, -1, 0);
  SDL_SetRenderDrawColor(renderer, 255, 255, 255, 250);
  SDL_RenderClear(renderer);
  SDL_RenderPresent(renderer);
  SDL_Delay(2000);
  SDL_DestroyWindow(window);
  SDL_DestroyRenderer(renderer);
  SDL_Quit();
  return EXIT_SUCCESS;
}

The first thing we do is call SDL_Init and pass the flag SDL_INIT_VIDEO, which initializes the video subsystem. SDL has many initialization flags that you can bitwise OR (|) together to initialize multiple subsystems at once. For example like this

    // Initialize SDL with video and audio subsystems
    if (SDL_Init(SDL_INIT_VIDEO | SDL_INIT_AUDIO) != 0) {
        printf("SDL could not initialize! SDL_Error: %s\n", SDL_GetError());
        return 1;
    } else {
        printf("SDL video and audio initialized successfully.\n");

But we will stick to the video subsystem for now. Next we will call SDL_CreateWindow. It takes in a title, x and y for the window position, width and height for the window size, and some flags. If we go to the wikipage for SDL_CreateWindow we will see the function prototype, a description of its parameters (including flags that can be passed), and the expected return values on failure. This is how I knew what that I wanted to pass SDL_WINDOWPOS_UNDEFINED for the x and y, and let the operating system handle window placement.

Moving on, we create our renderer with SDL_CreateRenderer. We give it the window we created, so we can render to it, and pass its index parameter -1 to initialize the first rendering driver that can support our requested parameter flag of 0. You will always pass -1 as the index parameter unless you have a good reason not to. For the render flag we pass 0 which defaults to SDL_RENDERER_ACCELERATED (using hardware acceleration for the graphics) if it is supported on your system. If you want to be more explicit you can pass SDL_RENDERER_ACCELERATED instead. Just like with the SDL window, we write an if statement to check if the renderer was created so that we don't accidentally use it if it hasn't been initialized.

Next we call SDL_SetRenderDrawColor() and pass it our renderer, as well as 4 integers with values from 0-255. The 4 integers correspond to Red, Green, Blue, and Alpha values of a color. The alpha controls the transparency of the color, while setting the R, G, and B values to various levels allow you to create any color you want between 0,0,0,255 (Black) and 255,255,255,255 (White). SDL_RenderClear() takes our renderer and clears it with the white color we set using SDL_SetRenderDrawColor. SDL_RenderPresent() displays our graphics to the screen (just a white window for now) and then we call SDL_Delay(2000) which specifies a number of milliseconds to wait before moving onto the next piece of code. Normally the rendering code will be in a while loop that will constantly update until the user quits the game, but for simplicities' sake, we will stick with a delay for now.

SDL_DestroyWindow safely removes our window once we are done with it. If for whatever reason the window was not initialized, it is still safe to call this on the window variable. The same goes for SDL_DestroyRenderer. It does the same thing as SDL_DestroyWindow and cleans up our renderer. Finally we call SDL_Quit which cleans up the systems we initialized before we close our program.

And that is it, we've created our first window in SDL. In the next tutorial we will look at how to draw text on the screen.

One last thing to note. I will not be abstracting many things to functions or multiple files in these first few tutorials. I believe it's important when you are learning a new library, to keep it as simple as possible. As the code gets longer this will become a bigger pain point, and that is good. You will have a much clearer picture about what we should abstract, and why we should abstract it, as you become more familiar with SDL. Feel free to come up with your own abstractions as you see fit

FAQ

Why do we clear the screen with a color?

We clear the screen with a color so that the previous frames pixels don't interfere with the next frames pixels. For example, if we have a square on the screen that we are moving with the WASD keys, if we don't clear the screen, then square will smear across the screen as the old pixels from it's old position are not "wiped" away.

Why SDL and not Raylib?

Raylib is an awesome C library for creating games, and Raysan specifically made it for teaching. He did a comparison at one point between the two frameworks, though it is a little dated at this point. It is easier to learn and make new FFI bindings for Raylib than it is for SDL and Raylib comes with more convenience features out of the box. You are not making a mistake if you choose Raylib. But SDL has been around over twice as long as Raylib. Many of the open source projects I'm interested in contributing to (Doom Source Ports, OpenMW, and others were started before Raylib existed and use SDl2. Since these projects use SDL so will I. SDL2 is also a little lower level than Raylib, and requires you to work at a lower level with it's subsystems. This means instead of placing drawing code between a BeginDrawing and EndDrawing block like in Raylib, you have to set up the renderer, create textures, copy them to the GPU, before finally presenting it to the screen. I find this process to be enlightening.

Call To Action 📣

The continued rise of Handheld Gaming

Diego Crespo — Thu, 08 Feb 2024 14:19:39 +0000

My very first handheld game was probably the ring toss game… But in all seriousness it was my fathers Game Boy in the late 90s. I distinctly remember playing Star Wars and I don’t think I ever beat it.

I remember handheld gaming being all the rage growing up, and I have fond memories of playing on Game Boys, Game Boy Colors, Game Boy Advances, PSPs, and DS'. Like many, after about the PSP era, I moved away from consoles and handhelds in favor of PCs. But since getting back into handheld gaming with my Steam Deck, I was shocked to see there had been a Cambrian explosion of handhelds. Many are from major players in the tech space, though some are from companies I've never heard of. It feels like we are in a renaissance, or, that is what I thought the angle of this article was going to be when I started writing it. But in actually researching handheld history, I've come to the conclusion that while I had abandoned it, it hadn't gone anywhere.

A lightning Tour

Let's take a look back at one of the earliest handhelds. For the sake of brevity I'll only consider handhelds that could play more than one game, so no Game and Watches, or single game electronics. In this vein the honor to the first handheld gaming console that fits our criteria is the Microvision created in 1979.

It looked more like the iClicker I had in College than a gaming device, but it had 12 different games that it could play. Clocking in on a CPU that ran at 1kHZ, a number I have never seen next to a CPU, It's honestly hugely impressive it could play anything.

But just 10 years later we would be introduced to one of the most popular handhelds of all time, by one of handheld gaming's most prolific supporters, Nintendo. The Game Boy would be a smash hit, bringing handheld gaming to the masses. Nintendo has certainly not slowed down since then and if we look at the timeline from the Game Boy to the Switch we get a history that spans from 1989-2021 with no signs of stopping.

Game Boy: Released on April 21, 1989, in Japan, July 31, 1989, in North America, and September 28, 1990, in Europe. The OG.
Game Boy Pocket: Released in 1996, it was a smaller, lighter Game Boy that required fewer batteries.
Game Boy Light: Released only in Japan on April 14, 1998, this model featured a backlit screen.
Game Boy Color: Released on October 21, 1998, in Japan, November 18, 1998, in North America, and November 23, 1998, in Europe. Backwards compatible with the Game Boy! Contained a 15-bit color palette instead of the 4 in the original Game Boy.
Game Boy Advance: Released on March 21, 2001, in Japan, June 11, 2001, in North America, and June 22, 2001, in Europe. Backwards compatible again! Hardware that was more powerful than the SNES from a decade prior.
Game Boy Advance SP: Released in February 2003, it featured a front-lit screen and a clamshell design.
Game Boy Micro: Released on September 13, 2005, in Japan, and subsequently in other regions. A slimmer version of the original GBA.
Nintendo DS: Released on November 21, 2004, in North America, December 2, 2004, in Japan, February 24, 2005, in Australia, and March 11, 2005, in Europe. Successor to and backwards compatible with the Game Boy Advance.
Nintendo DS Lite: Released in early 2006, it was a slimmer and lighter version of the original DS.
Nintendo DSi: Released on November 1, 2008, in Japan, and in 2009 in other regions. No slot for GBA Games. Two cameras, SD Card slot, and other enhancements.
Nintendo DSi XL/LL: Released in 2009, it was a DS that larger screens.
Nintendo 3DS: Released on February 26, 2011, in Japan, March 25, 2011, in Europe, March 27, 2011, in North America, and March 31, 2011, in Australia. Successor to the DS with the most notable feature being the 3d graphics, 3 cameras, and AR capabilities.
Nintendo 3DS XL: Released in 2012, this version featured larger screens.
Nintendo 2DS: Released on October 12, 2013, as a budget version of the 3DS without 3D capability.
New Nintendo 3DS: Released on October 11, 2014, in Japan, and 2015 in other regions. Enhanced performance, better 3d, a C-stick, and built in NFC.
New Nintendo 3DS XL: Released alongside the New Nintendo 3DS, with larger screens.
New Nintendo 2DS XL: Released on July 13, 2017, as an upgraded version of the 2DS.
Nintendo Switch: Released on March 3, 2017, a hybrid console, usable as docked as a home console and undocked as a handheld device.
Nintendo Switch Lite: Released on September 20, 2019, features non removeable joycons.
Nintendo Switch OLED: Released on October 8, 2021, it's a Switch, but with a nicer screen.

Phew! That was a lot. While compiling this list a couple of things became apparent to me.

Nintendo has been keeping the handheld dream alive, even after other hardware manufactures had left the space.
Nintendo loves to sell you the same handheld over and over again.

Multiple Game Boy's DS' and Switches. I wouldn't be surprised if we see a Switch XL at some point. And you already know there will be a Switch 2 Lite.

But while Nintendo never stopped making Handhelds, the list of handhelds we got from 1989 to ~2013 ranged for weird, wacky, cool, and everything in between. Here are some of them

Atari Lynx (1989) - First handheld console with a color LCD screen.
Sega Game Gear (1990) - Competitor to the Nintendo Game Boy, known for its backlit color screen.
Sega Nomad (1995) - Handheld version of the Sega Genesis, allowing players to use Genesis cartridges.
Tapwave Zodiac (2004) - Short lived device that functioned as both a PDA and a gaming console.
Sony PlayStation Portable (PSP) (2005)- Known for its powerful hardware, multimedia capabilities, and wide game selection. I had one with a skin covered in green skulls, and it was incredible.
GP2X Wiz (2009) - An open-source, Linux-based handheld console produced by GamePark Holdings.
Pandora (2010) - A combination of a handheld game console and a mini PC, running Linux.
Sony PlayStation Vita (2012) - Successor to the PSP. Featured a touch screen, rear touchpad, and high-quality graphics. Please bring it back Sony.
Nvidia Shield Portable (2013) - An Android-based device that combined a game controller with a screen, capable of streaming games from a PC.

One interesting thing to note about this time. With devices like the Nvidia Shield, we begin to see the rise of handheld streaming devices. This is a lot more common now with the likes of the PlayStation
Portal, and Logitech G Cloud (with an honorable mention to the Steam Link).

I would be remiss if I didn't at least talk about the most common forms of handheld gaming of our generation, mobile gaming. While I do remember playing games like Dragon's lair on my father's Sprint flip phone...

It was when we got smartphones where I really saw the quality of mobile gaming blow up. I remember games like Zenonia back in 2009 being awesome. I couldn't believe I was playing such a fully featured rpg right in the palm of my hand at that time. I remember sitting back and playing it for hours on my landscaped iPod in a wooden chair with no cushion, my back and eyes would never permit that now.

This was pre candy crush too, so the dark patterns were either non existent, or much simpler at the time. You could even buy a game once, and never pay for it again (shocking I know). And remember Infinity Blade? Mobile gaming may have truly peaked in 2010.

But if we include phones on this tour, we'd be here all day so let's get back to dedicated handhelds. Not only have we had great handhelds for the last 35 years, if you look at the top 5 best selling consoles of all time...

PlayStation 2
Nintendo DS
Nintendo Switch
Game Boy/Game Boy Color
PlayStation 4

We see that three out of the top 5 are actually handhelds. So with that fact, and with this article having mentioned over two dozen handheld devices at this point, It's safe to say handhelds, and handheld gaming, never went away. In fact I'd say it's more popular now that it has ever been!

The experience is also so much better than it used to be. For one, I don't have to go through dozens of AA batteries a month anymore. And two, they don't feel cut down. Using my previously mentioned Star Wars Game Boy game as an example, I recently found out that this is what the NES version looked like.

Shocking! I would have loved to have my Game Boy version look like that back in the 90s. By the Game Boy Advanced era in 2001, we were able to create incredible 2D handheld experiences, but we were only just getting to the point where we could render anything impressive in 3D. Sure you could program a 3D GBA game if you were a literal programming God like Randal Linden, but unless you are willing to write 200,000 lines of highly optimized assembly then we still needed a few generations before this was feasible for your average programmer.

But fast forward to the PSP era, and we were beginning to see what no compromise 3d handheld experiences looked like.

And by the time we got to the Switch, it was clear that while certain games might have struggled to hit their 30fps target sometimes, we weren't getting stripped down version of a game originally made for PCs and consoles anymore.

And now in the more modern times (a sentence that will age like milk) we see many other players in the space besides Sony and Nintendo. There are Android, Windows, and Linux based handhelds, some from well known brands, and others from rising stars...

GPD XD: 2015
GPD Win: 2016
GPD XD Plus: 2018
Abernic RG351P: 2020
Retroid Pocketc 2S: 2020
Miyoo Mini: 2021
Ayn Odin: 2022
Steam Deck: 2022
Miyoo Mini +: 2023
Logitech G Cloud: 2023
Lenovo Legion Go: 2023
Ayn Odin 2: 2023
Asus Rog Ally: 2023
Steam Deck OLED: 2023
PlayStation Portal: 2023
Msi Claw: Sometime in 2024

And it's exciting. It feels like we've hit an inflection point with handhelds. With devices like my Steam Deck, I don't feel like I'm giving anything up when I'm using it. But at the same time, I'm excited for every new iteration. It feels just like how it was in the late 90s and 2000s where every console generation, or graphics card generation, was a noticeable improvement over the last. And with the Switch 2 rumored to be announced later this year, it seems like that excitement isn't going to be slowing down anytime soon.

Call To Action 📣

https://www.deusinmachina.net/p/the-evolution-of-valves-source-engine

Geek Mythology: The Religious, and Spiritual Folklore surrounding Programming

Diego Crespo — Mon, 12 Jun 2023 01:06:50 +0000

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 faith. 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 and on. Programmers have had their preferences since the age of computing. But beyond simple preferences, there are those who elevate their personal choices to moral imperatives. 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 Minix

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.

Mysticism 🔮

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 Koans 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 koans 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 Programming. 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.

Faith 🙏

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 can. 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 4, 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 errors, and a whole list of hardware errata that seeks to thwart your understanding. This is on top 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 quote. 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…

Folklore🪕

Finally there is a lot of folklore surrounding programming. There is literally a website called folklore 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 Code
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? 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”. 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 Delphi. We take our actual faith and ask What would Jesus do? if he were programming. We borrow terms like Daemon, we have Chief “Evangelists” 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…

"Commit to ~~the Lord~~ GitHub whatever you do, and your plans will succeed."

Call To Action 📣

If you made it this far thanks for reading! If you are new welcome! I like to talk about technology, niche programming languages, AI, and low-level coding. If this interests you there's more where that came from on my Substack. I’ve recently started a Twitter and would love for you to check it out. I also have a Mastodon if that is more your jam. If you liked the article, consider liking and subscribing. And if you haven’t why not check out another article of mine! Thank you for your valuable time.