When the Walls are Closing In

For my Distributed Computing class, I'm writing an Actor Computation framework in Ruby. I've got a little code written and the rudimentary architecture laid out.

So far, I've had three, "Oh Shit... is this gonna be a huge problem?" moments.

The first came when I was trying to figure out how a computation on one machine was going to be delivered back to the place where it was requested. I knew that this was going to be something that I'd need to solve in the course of writing the framework, but I hadn't yet worked out a theoretical solution. I eventually figured out what I needed to do when I was in the shower (a classic "Eureka" moment to be sure).

The second came when I was trying to determine how an Actor would migrate from one machine to another without losing any messages sent to it. I had a little help with this problem because my Professor has written a slightly similar system that implements a solution to this and he pointed me in the right direction.

The third came over the course of the past few days when I realized that I had failed to figure out how short lived actors would be garbage collected (that is, actors who, once no one holds references to them and who have exhausted their message list, are deallocated). I began poking around the Remote Method Invocation library I'm using and looking for discussions on Distributed Reference Counting. The walls started closing in. It looked like I was going to have to write something that would be brutish and nasty and abusive of Ruby's meta-object model.

I didn't like it, but I became resolved to my fate. I'd just have to find the tests for the RMI library to make sure I wasn't breaking anything. Oh well, life sucks and then you die.

Today, I was thinking about the probelm again. Then I remembered something: The objects those distributed references point to are mobile! The RMI library's distributed references are static! I couldn't proceed with my nasty, brutish solution anyhow.

Oh noes.

Not 20 seconds later I thought of a solution that was immensely more satisfying and would be much more consistent with the rest of my system if not necessarily easier to program.

I tell you this, not because I want you to be impressed with how fast I think my way out of problems and into solutions, but because of how I came to my solution: Another Level of Indirection. My problem was because I was thinking to close to the tool I was using, I was trying to come up with the answer to a problem that was bound by the constraints of the wrong domain. I should've known better whilst I was fretting over what my library does to just go up a level and not worry so much.

If Lazines, Impatience, and Hubris are the three greatest traits of a Programmer, Indirection is surely his greatest tool.