Systemantics: Application Trumps Intent
Systemantics: Application Trumps Intent
What you plan and what takes place needn’t be exactly similar.
This was originally penned on the 7th day of October, 2020. It was a Wednesday. It has been reprinted here for posterity and/or austerity (whichever you prefer). Enjoy.
Yesterday morning I awoke from a dream, rushing to exclaim to my husband in groggy-eyed furor a law of systemantics I came up with a minute before in my sleep. This is what was ideated towards the end of my soft, REM-laden sleep:
The application of a system utterly annihilates the system’s intended use case. Of course, it is nice when there is overlap, but they have no relationship.
Save a little paraphrasing, this immediately went up on my Twitter afterward. Soon I recalled too that it was a solution to an argument I had some days prior, regarding somebody’s frustration with a system misbehaving.
They had an assembler of some kind that, per some format spec, was intent on outputting NUL bytes mid-stream in an otherwise valid UTF-8 character stream. They were frustrated and angry with it, and when I attempted to solve the problem by asking them questions they pointed their anger at me. It was then I knew they had no technical problem at all.
Nonetheless, the following day I was reading about character encodings, and discovered something called “Modified UTF-8” that basically solved their exact use case. I posted it and tagged them, and unsurprisingly, they were quick on the draw to find reasons why it was a bad idea, in the typical “X considered harmful” fashion of counterproductive recreational programming.
As far as I was aware, Modified UTF-8 solved their problem quite neatly. They said it was a bad idea, but given their struggle with the software to do what they meant for it to do at the outset, and the fact that it still remains a problem for them to this day, I do not believe that is an honest assessment at all.
As I expounded on in later Tweets, the truth about this is simple. If you don’t understand the total system you are dealing with—in more precise terms, you lack the ability to investigate and discern the system’s behaviour in exact terms whenever and wherever it needs to be known—you are jolly-well-fucked and shit-out-of-luck with fixing its woes anyway and may as well embark on a great rewrite.
There’s no sustainable path in system design without such basic guideposts. If this kind of thing feels out of your wheelhouse, consider writing something besides systems with your time for code. But if you’re intent on writing systems, the last thing you should be doing is decrying C as a “broken language” like the maintainer from the story above. The first thing you should be doing is getting comfortable with GDB if you haven’t already. And more importantly, say goodbye to generics, because they’re the least obvious thing for anybody to read when it comes to comprehension. You’re going to need that to understand a system.
Hey! Thanks for reading. This one is a republishing, so it’s a free read, as before. I run this Substack to help break myself out of relative poverty and earn the white collar lifestyle I was not endowed with growing up. It’s $5.55/month to subscribe, or $55.55/year. That’s like the Interstella movie, or something. Think Daft Punk. Totally worth it.