Weekly Wrap-up Post #31

Programming horrors, a few book recommendations, and my experience in using Twine in the classroom...

The first week “post-book” has been enjoyable. It’s not so much that I have any more free time than I did before, but I don’t feel guilty in the way I did when I was behind on book work. Now I just feel the normal amount of guilt from being behind on many, many things, and not the added burden of having an entire book on my docket…

Lyndon regards our current weather very dubiously. Yesterday it was hot enough to wear shorts, but not today…

When I wrote up my first post on the Weapons Effects Display System (WEDS) back in January, I always intended it to be a multi-part post, although what would be in the second post was always a bit speculative. At the time I wrote it, I had a few reports on the WEDS system as it had been built, but had also contacted Lawrence Livermore National Laboratory to see if they’d be able to send me references to other reports that I’d found cited in various indices and databases online. I wasn’t able to get all of them, but I was able to get a bunch of them, and they allowed me to flesh out the history of the WEDS system in a lot more detail than I had actually realized I could when I wrote the first post. You can read the results in this week’s Doomsday Machines post, which is the I am sure much anticipated followup:

I mentioned in the article that the actual programming code for the WEDS MOD II is… amazingly unpleasant. Here is a snippet from the fallout code, to give you an idea of how low-level it is. This is about half of a function that apparently is just meant to calculate the square root of a number — that’s how low-level this is!

Just… yuck. It’s amazing to me you can program anything if you have to construct your basic math functions with the equivalent of stone tools. Note that all of that text on the right, which seems a little descriptive, are the comments explaining what the actual code is doing. The actual code are those things on the left that look like STA SR4+2 and so on, which is doing things like manipulating numbers stored in the memory and controlling the program flow.

Every time I see assembly code being used to do anything complicated I am always amazed. There is a YouTube channel called Displaced Gamers where the creator makes videos analyzing bugs in Nintendo Entertainment System (NES) games from the 1980s, and I find myself somewhat endlessly fascinated/horrified by it, because all of the NES games were written in a kind of assembly language as well. I can sort of follow it, most of the time, but the idea of trying to make a game with any complexity out of such a low-level language seems practically impossible to me. I’m struggling to come up with a good analogy for non-programmers…