My coding interests

In this article, I want to give you an overview over my current coding interests that might find their ways into articles on this blog.

I use Unix-like systems for many years now. I switched from Windows to Linux in 2008 and was at peace for a long time, till I learned about even better (to me) systems. Enter *BSD. But this is for another article.

I like good graphical interfaces, but I often prefer to work with the terminal. This sets me apart from most of my colleagues, which even choose to ridicule my "old-fashioned" ways.

My taste for Unix also found their way into my coding: I prefer C and Go for my native binary needs, while writing scripts in Perl and Python.

I prefer coding in simple languages that give me a huge amount of control over the machine. C again has me covered here, but I also follow the development of other languages like D, Zig, Nim or Rust, as they seem all promising to me.

I also like getting my hands dirty. I find Forth and Assembly fascinating and will try to get some experience with them in the future. One interesting project could be writing a game for the Game Boy, as I also am very interested in game programming in general and game programming for retro consoles especially.

I am also interested in reverse engineering and Ghidra, so that is another way to interact with the "lower level" that I enjoy and that I want to learn more about.

At work I have to code with Java, C# and Powershell. These are neither unixy nor low-level. This makes me dearly miss the simplicity of my private projects. One aspect are frameworks. I believe that Frameworks are a huge productivity boost as long as they just work. But you cannot use them (or any other abstraction) to avoid having to learn the system below the abstraction. This is something my colleagues and many other programmers seem to forget to easily. And sometimes frameworks will break or act surprisingly.

Take Hibernate as an example: If all you do is simple CRUD, maybe you do not need to know much about databases and sql. But then, suddenly, you are confronted with slow database performance or with weird behaviour you don't understand. And then you have a problem: You now have to understand it in order to fix it, and this means not only learning the layer below (the database), but also the inner workings of the framework. Is it a bug in Hibernate, or are you using it wrong? Who knows?

I prefer to write my own abstraction over the database any time. I believe database access is too important to most software for it to be a part of your application that you don't understand too well.

Hiding complexity is like hiding your stuff below your bed. Looks more tidy than leaving it lying around in your room, but I wouldn't call it cleaning up, the chaos is still there.

Having read until this section, you now know that simplicity is the big concept for me in computing. We are building huge stacks of layers over layers that all should free as from the shackles of the lower layers, but instead just add more complexity that we have to deal with.

Take a look at the Linux audio frameworks and compare them to sndio which just works. Look at the modern web with ever-changing frameworks and languages that compile down to the Javascript, CSS and HTML that no one wants to deal with. Look at electron, which creates nice, but horribly performing GUI applications that I will not touch unless I'm forced to. Take a look at systemd which is like I wrote over frameworks: Nice as long as it works, but hard to understand when it stops working. And it is not a question of if, but a question of when it will malfunction.

I try to reclaim being able to understand my own computing systems. I try to work with and work on software that is understandable and that is efficient and correct by reducing needless complexity.