One Tiny Change
Hello, loves!
A tiny article about one tiny change. Some thoughts on whether it matters. Tout le monde déteste l’IA.
I haven’t looked at the code yet this morning, but if memory serves, there’s a bit of Feature Envy we might want to deal with. Let’s see:
class DungeonView:
def illuminate_around_dot(self):
dot = self.dungeon.player_cell
if not dot: return # crock to allow a test to run
room = dot.room
radius = 1000 if self.dungeon.dot_has('a brilliant torch') else 4
for cell in room:
if cell.manhattan_distance(dot) <= radius:
self.illuminate_cell(cell)
def illuminate_cell(self, cell):
sprite = self.keyed_sprites[cell]
sprite.visible = True
for content_sprite in self.keyed_sprites.content_at(cell):
content_sprite.visible = True
In illuminate_cell, we have two references to our KeyedSpriteList keyed_sprites, and each time we grab one or more sprites that it contains and set the sprite’s visible flag. This method, though it does refer to one of our instance variables, isn’t really about that variable: it’s about that variable’s contents.
The signs and portents here suggest that we might do well to put this responsibility into the KSL rather than here. Like this:
class DungeonView:
def illuminate_around_dot(self):
dot = self.dungeon.player_cell
if not dot: return # crock to allow a test to run
room = dot.room
radius = 1000 if self.dungeon.dot_has('a brilliant torch') else 4
for cell in room:
if cell.manhattan_distance(dot) <= radius:
self.keyed_sprites.illuminate(cell)
class KeyedSpriteList:
def illuminate(self, cell):
sprite = self[cell]
sprite.visible = True
for content_sprite in self.content_at(cell):
content_sprite.visible = True
Test for illuminate passes. DungeonView now down to 87 lines. Of course those lines are mostly moved over to the KSL, although they are simpler once moved. Commit: move cell illumination to KeyedSpriteList.
What Difference Does It Make?
Darn good question in these days of LLM/”AI”. My answer is that it matters to me. The new code is better than the old, not just subjectively. It used to be that the illumination code knew two methods on the KSL, and those methods were a bit complex in that one returned a sprite and the other a collection of sprites. The code reflected that and furthermore, anyone (or any being) working with it needed to be aware of all that. Now the code just says to illuminate a cell.
The old code was coupled to the details of the KSL. Now it is coupled to its capability. Furthermore, the old code was the only prod-side reference to the content_at method of KSL. Now that method can be inlined or made private.
The old code contained an algorithm with a reasonable name, illuminate_cell. Now it just says illuminate(cell). The algorithm, in simpler form, is inside the KSL class, which is now the only object concerned with the details of how it works.
A thing about your [expletive deleted] LLM is that it does not have intention. It may have very good ability to analyze code, comparable to the ability of a good refactoring browser. In that, it is better than I am, in that it can and probably will make consistent changes throughout the program. It has no purpose, no mind, no desires.
In these days of massive computational power, will the LLM’s raw power and your own computer’s increasing power mean that whatever issues arise will be absorbed by raw computational capability? Or will the LLM ultimately bury itself in the program it “writes”?
I wish I knew. I will not use one: personal moral issue as frequent readers know. But I would like to know this enemy, because we need to know an enemy to defeat it.
But I know this: I care about my code, and I imbue it with my caring, and I do my best to make the code I write express my intention in writing it, just as I do my best to express my thoughts in these articles.
And, to me, that’s important, and I can do it. I hope that you can do the things that are important to you.
See you next time!