God is a software engineer. Change my mind.

Food for thought while having food and thoughts

I just had lunch having some Char Siu pork with ginger and wine sauce along with some brown rice while staying in Glasgow for work matters. As I finished my food and moved back to my pint of Cobra I started thinking about the original G, God.

my thought triggering food
The food I had when I started to seriously think about writing this post along with the drink that helped writing the first 800 words or so on my phone.

I consider myself somewhat religious and believe there is a god somewhere beyond our perception. But what would he be like? I like to think he is a sort of software engineer. He had some time on his hands and thought he would write some code. The rest is history (in any sense you want I will not judge nor care).

Might be true, might not be. But what if we all were an advanced piece of software? Would that not be an incredible feat? Where did he start? Only thinking about the way we function and interact with our environment is mind-blowing. We eat food that makes us feel better or sick. Practising sport makes us feel happier, tired or even confident. So many things can interact with us in ways we barely understand.

I was about to start some sort of philosophical post but I can do something closer to my everyday work. Let’s just write some code. I’m not talking about creating the universe and everything in it. On one hand, I’m not that good (yet) and on the other hand who would use it or maintain it afterwards? Nobody’s got time for that! Okay, god is confirmed as a software engineer.

god is a software engineer change my mind
Seems like a pretty accurate depiction to me and yes I made that myself. That may not be the best piece of art you’ve ever seen but it’s original content.

Time to literally play God

Have you ever wondered how eating works?

Next, let’s do a bit of design. What would God do to engineer the process of eating something? Eating is the first step of that whole digestion process. Yet both are separate. Since I assume that the All Mighty is a Clean Coder, we will split that into two actions Eat() and Digest(). These will be the first methods of our Digester interface. Why Digester and not Human? Well, as far as I know, we are not alone able to eat and digest stuff. Animals and some plants can eat and therefore digest. Let’s have a first look at our Digester.

public interface Digester
{
    void Eat();
    void Digest();
}

Eating is consuming something that can be digested. This means our eating function will take in parameter something that can be digested. But since people are stupid they may try to eat things they can’t digest. Let’s create our interface Item to be used as a parameter for Eat().

public interface Item
{
}

Now we can create Digestible which will extend Item.  In our context, an item is something that we can interact with.

public interface Digestible : Item
{
}

So actually we have Eat(Item)  instead of Eat(Digestible). So little tip for God, please change your interface for V2. I know how hard it is to write software for users that won’t necessarily be the sharpest but come on. Or remove free will. Actually, both would be the same. Nevermind, good job. Let’s look at that updated and approved by God Digester interface:

public interface Digester
{
    void Eat(Item item);
    void Digest();
}

So back to my version. We have our Eat(Item) method, what now? If we stick to the simplistic happy path of the whole eating thing not much more is needed. Life is complicated so if it is a software it will require a more complex implementation.

Normally you would eat stuff that you are supposed to eat then you digest everything you ate since your last digestion. Implementation wise you would have a FIFO stack to handle storing items. But what happens when you eat something you should not eat?

Whether it is a not-so-fresh burrito, cyanide or other items unpleasant things follow depending on your preferences. I would even go so far as to call these exceptions. If only there was such a concept in software development… Which brings me to:

Exceptions a.k.a things you may not put in your mouth but God lets you do it anyway

Let me introduce you to a guy you may not know, 2008 JD (pronounced noob). As one does, 2008 JD would suggest throwing an exception if someone tries to eat something they can’t digest like a big rock. No, 2008 JD is not stupid but has a lot of learning to do. Indeed, 2008 JD did not know what a variable nor a compiler was so do not take advice from him.

2018 JD will tell you that you do not want to have the same reaction to everything you can’t digest. What if that exception just kills the Digester? Wouldn’t that suck if you just died from anything you’re not supposed to put in your mouth? That would suck, big time. We want to treat digestion with some more finesse.

Things that you literally cannot digest because people tried and had troubles

Back to the rock thing, we would count it as an item that you can technically eat but not digest. so let’s make our Digester a little less abstract. To do that we will make it an abstract class that can choose not to digest everything that gets eaten. Actually, it would make more sense now to break the Digester into a Eater and keep the Digester defined by its ability to digest. Now let’s see what our updated Digester would look like.

public interface Digester
{
    void Digest();
}

Ok, now I present to you the Eater class that now chooses what it can or cannot digest.

public abstract class Eater : Digester
{
    private Queue  throat = new Queue();

    public void Eat(Item item) {
        if (item is Digestible food) {
            throat.Enqueue(food);
        }
        else {
            throw new LiterallyCannotEatThatException(item);
        }
    }
}

Now that got that big rock out of the way we can finally move to simpler stuff. Things that you can swallow and digest with more or less pleasure.

Things you can digest more or less safely

But how does the food impacts us? Well, when you eat something it has an impact on you, it interacts with you. When you eat something, you know based off past experiences or common knowledge how it should taste like and how it should make you feel. Note the use of “should” here.

You cannot look at something you want to eat and know exactly what it will do to your Digester body. If you tell me otherwise you are simply lying or God. How would God know how the food he created interacts with a Digester I hear you ask? The same way I know your code doesn’t compile Robert.

All one has to do to understand how a piece of software works is to look at the code. Now in order to design our interaction with food we need to resort to these good old design patterns. Let’s skip the part where I teach you about the design patterns and right to the part where you go and read about them yourself. Now, which design pattern would fit better our interaction with food? Right now I think about the Visitor pattern.

After ingesting food, food goes through a journey of sorts inside you. It does things to you through the interface your body allows it to access. You get fatter, happier, healthier, drunker based on what you consume. Food or Digestible can make you sick or even kill you. Think food where you forgot to remove the venom correctly because you’re such a maverick. If you come up with something that makes more sense I am entitled to consider you’re wrong but still feel free to share with me anyways which pattern you would put there. In order to remain as flexible as possible, we will say that items can interact with other items. Meaning that our Digestible which extends Item now has an entry point for Digester to be visited.

public interface Item
{
    void Interact(Item item);
}

Now let’s have a look at our updated Eater that is also an Item. Cannibals are a thing but even staying away from that, eaters can be animals or plants and we eat them. That’s the circle of life, look it up. So I was saying, yep updated  Eater implementation:

public abstract class Eater : Digester, Item
{
    private Queue throat = new Queue();

    public void Eat(Item item) {
        if (item is Digestible food) {
            throat.Enqueue(food);
        }
        else {
            throw new LiterallyCannotEatThatException(item);
        }
    }

    public void Digest() {
        while (throat.TryDequeue(out var digestible)) {
            digestible.Interact(this);
        }
    }

    public void Interact(Item item) {
        // empty like most relationships...
    }
}

Time to venture in a zone of danger

Now we have our simple strategy in place for an eater to consume items. What now? We need an interface to express that we are mortals and that food does things to us. That sounds a little too specific so I will just add one method to Item because it’s getting late and I need to go and work in the morning. (Yes these things take time to write…).

Item will now implement die(). Everything can die, technically or philosophically and it’s getting late so I’ll stick to that. Let’s now see how food can make use of that through the Visitor pattern and complete this post. (I know you have been here for like 5-10 minutes but I have been writing for almost 10 hours straight so bear with me). Where was I? Yes, items can die:

public interface Item
{
    void Interact(Item item);
    void Die();
}

This means that now eaters can die:

public abstract class Eater : Digester, Item
{
    private Queue throat = new Queue();

    public void Eat(Item item) {
        if (item is Digestible food) {
            throat.Enqueue(food);
        }
        else {
            throw new LiterallyCannotEatThatException(item);
        }
    }

    public void Digest() {
        while (throat.TryDequeue(out var digestible)) {
            digestible.Interact(this);
        }
    }

    public void Die() {
        // Except for PewDiePie a.k.a. 0 deaths
    }

    public void Interact(Item item) {
        // empty like most relationships...
    }
}

And now the finally the food that literally kills eaters:

public class ForbiddenFruit : Item
{
    void Interact(Item item) {
        item.Die();
    }
	
	void Die() {
    }
}

That fruit is no joke. Thanks again Eve for that because of you are all going to die. At some point. Eventually.

Away from the original sin and back to the original point

I may have only put an afternoon of formulated thought into this but I don’t believe my mind will be changed on this. I already had a few sparks about this in the past but not the point of blogging. God is a software engineer, definitely the best there is the best there was and the best there will ever be. At least for now.

I mean look at the snippets of design and code here. And I’m supposed to be a decent software engineer building complex systems and stuff. Yet this is probably the dumbest version you will read of life explanation/emulation using code and software principles.

Personally, it is the dumbest attempt I read so far but also the first. Who knows maybe someone will find a bug in the Matrix to confirm this. What if we don’t even have a counterpart on the other side? If you reached that level of uncertainty, would you even want to scratch the surface? I may have gone too deep, too fast. Quick a gif to make the post light again.

cute dogs are God's gift
That’s more like it!

I hope you enjoyed this read and will be back for the next one. Or the last one. Whichever you pick I will be there. Will you?

Leave a Reply