programming

Jul 30, 2025 ∞

A light exercise in vibe coding

A few months ago I tried vibe coding an ant colony simulator, but in the end it didn’t work out. I did mention that I had had successes in vibe coding, and lately I had one of those again.

For my previous post I needed to embed several YouTube videos. That, however, is very cumbersome when you’re blogging with your phone, as the mobile version of YouTube does not have the option to easily just copy the embed code, unlike the desktop version, so it was about to turn into an exercise in frustration.

But lo and behold, ChatGPT to the rescue. I gave it this prompt:

Elevator Saga game

What should happen if you’re on the tenth floor of a building and push the button to call an elevator? Obviously, the elevator should come to you. But what if it’s going up at the 11th floor at the moment, as someone told it to take them to the 15th floor? Well, do that first, then get to the tenth floor. But what if, meanwhile, someone calls it to the 14th floor, wanting to go down? Maybe pass that floor when going up, but stop there on the way down to the tenth floor. But what if you, on the tenth floor, want to get to the 16th floor? Maybe pass the person waiting the 14th floor after all. And what if there are multiple elevators in the lobby, which one should be dispatched and where?

Robot Battle, an old Windows game

In the 1990s and early 2000s I played this great game called Robot Battle by Brad Schick. It’s an open-ended programming game where you use a programming language called Robot Scripting Language (RSL) to program battle bots to shoot at each other. The bots look like tanks, consisting of a tracked body, turret, and radar. The arena is viewed from top-down and, in addition to the robots, would also contain mines that you would want your robots to avoid, and cookies that give you more energy. The game relied heavily on its community, initially connected via the Robot Battle Mailing List (RBML), later via the Robot Battle Registry web forum.

Random Things Sunday #8

A bit of Star Wars and some programming this week:

SC 38 Reimagined is a fan-made remake of the Obi-Wan vs Darth Vader fight in Star Wars Episode IV: A New Hope. The film is short but it has high production values. It makes the original Alec Guinness vs David Prowse battle look rather geriatric, following Vader’s aggressive fighting style seen in the prequel films and TV shows. This fan-film even has a Wikipedia article.
Google may have profiled me after my previous Random Things Sunday post, as that list contained a reference to a piece of game-making software, and then YouTube’s algorithm recommended me the Make tiny games video by Juniper Dev. The video is about retro game engines, such as PICO-8, that force you to be creative by limiting the resources you have at your disposal, but that can also be fully mastered due to their limited size. If one wants to make games, start small, and nothing is smaller than these engines!
Finally, Joshua Barretto did a great write-up Writing Toy Software Is A Joy, which I think is a good follow-up to the previous point about tiny games. The point of the post is that if you’re a programmer, you should have hobby projects too. You cannot know how, but they’ll pay you back when you’ll acquire knowledge you didn’t know you’d need. And it’s also just more fun to program 20% the work for 80% the results, rather than trying to account for every exceptional case like you’d do if you were writing production quality software, where the first 90% of functionality takes 90% of effort and the final 10% of polish takes the other 90% of work.

Apr 3, 2025 ∞

Saalo's Law of Software Development

When you’ve been long enough in the software development business you start to notice patterns. One of those patterns recently surfaced again when someone in my team floated the idea that our system should be able to read or write Excel files. I’ve seen and implemented this particular request so many times that I got inspired to write it down as an adage. I’ve dubbed it Saalo’s Law of Software Development and it goes as follows:

Every piece of enterprise software eventually evolves into either reading or writing Excel files.

I originally posted this just to the company Slack where my peers unanimously agreed that yes, this is exactly what happens. There’s something about spreadsheets that makes them the universal translator of the business world – no matter how sophisticated your system, someone always needs that Excel import or export function.

So there you have my humble observation on how enterprise software works. My law may not be as well known (yet!) as Hofstadter’s, Brooks', or Parkinson’s laws, but maybe one day. 😁