Running in circles, trying to reach to 5 kilometers, it has me thinking about loops in programs. It's a simple enough thing to conceptualize. Running 5 kilometers on my particular loop means making 3 rounds around the lake, but after the last lap, I need to keep going, running a little further in order to read the 5 kilometer distance I'm going for. Loops are often messy like that. You'll think, do this one for each item, but a loop isn't always over a collection. Like with my running loop, there's just one lake to circle, and I circle it 3 times. There's different kinds of loops. You have "for" loops, by which you keep track of an iterator, which is typically incremented once for each iteration. Then you have a "while" loop, which will keep going until some condition you specify is met.

In the case of my run - let's say you were to write a "for" loop. Make your iterator named loop_count. You'll start your loop_count at 0, run the circle around the lake, and reach back to the start line. Hitting that start line, the loop_count increments to 1 and you start the second lap. During the whole second lap, your loop_count iterator is 1. Reaching the starting line a second time, your loop_count variable increases to 2 and you start your third lap. When you reach the start line for a third time, the loop_count iterator increases to 3. Your conditional in the "for" iterator would say, "loop_count < 3", and you've circled the lake 3 time. However, if you stop there at that point, you've only run 4.8km, short of the 5km goal. If you make another loop, you have the opposite problem, overshooting the goal by 1.4km.

It's the same kind of problem frequently encountered in programming, where you have a loop by which you need to perform actions until reaching a certain goal, but then when you reach the end of the loop, you might face undershooting or overshooting your goal. In a more down to earth example, say you are asked to wait for 17 seconds. You might have a loop that waits for 5 seconds each iteration. If you wait 3 times, you hit 15 seconds, and if you wait 4 times, you overshoot your goal by 3 seconds.

The thing to do with this kind of problem is increase the granularity of your iterations. In the case of my 5km run, each loop around the lake ends up being 1.6km, so I can't reach my goal by taking a set number of laps around the lake. Instead, I can divide my path around the lake by 1km sections. On doing that, I can then take 5 stretches around to reach exactly 1km. Granted, the stretches of 1km on the second lap around the lake will be different than the stretches of 1km on the first, and the stretches on the third lap will be different than the first or second. This could be tricky if you have some such logic that depends on the actual location on the path, and not just the stretch that you're iterating over. Then you may end up performing some such logic on part of one stretch and completing the same on the next, a logical continuation that requires some state management to keep track of what thing is in progress from one iteration to the next. It's not a fanciful speculation of what could happen in program logic. This kind of thing happens all the time. It can be nettlesome to write, feel brittle to change, and confusing to read and follow.

AI doesn't make these kinds of problems go away, it just offloads the work of thinking about them to the computer. It can be fine to offload some tedious tasks to the computer and automate the creation of logic for some things or another, but sooner or later you just need to use your fleshy brain to figure out the things that need to be figured out. Offload all your thinking and soon you'll get soft. You'll be surprised that it becomes harder to figure out the things yourself. Kind of like offloading physical work to a machine. Sure, the machine can do more work, but if you never use your muscles then they'll also go soft. Don't let your brain nor your muscles get too soft. Use it or lose it.

Thinking about the problems encountered with logical loops further, inevitably the conclusion to be reached is to avoid the loops altogether. To think about what that means, consider the path around the lake again. We can't loop around it 3 or 4 times to reach 5km, and spitting the path into 1km stretches spits it in different ways for each loop around. What's the real goal though? It turns out, we don't necessarily want to loop the lake how many times. After all, if we went to a different lake we might need to loop around 8 times and some because maybe it's a smaller lake. Or we need to loop once and a half if it's big. The goal isn't how many times around, the goal is reaching that 5km distance. Furthermore, we don't really care how many times around we've gone, or which stretch we're on of looping it, what we really want to do is mute our headset when we come to the far side of the lake so we can hear the ducks and coots going about their business. That may be on different stretches of 1km or what not. All that doesn't matter.

What that amounts to then is abstraction. Instead of writing any kind of loop, you write your intentions. Leave the loops to the implementation. Here's your intention - run a 5km distance. Mute the headset when you encounter ducks. If your logic looks like that, it's gold.