Wednesday, May 27, 2015

Inheritance [and Regeneration]

The concept of original sin posits that we are born in a bad state. Our instantiation came with sin attached. It's inherited. And the only way to remove it, to decouple it, is to rebuild the object. This is the second life. It's like we are typecast from the object deteriorating from sin into a now non-bound version that more reflects God. Where, through this new Holy Spirit addition, we are not shackled to the function calls of sin.

Like typecasting, it is a whole new set of properties and functions. An integer isn't a string, but they can both be printed. I see our sin like that. First we are shackled to it, unable to choose differently. But the new one is openness. We can choose sin, or choose redemption, and live in a different way. Even if some of our actions look the same. We still eat food like we did before, we still need sleep and crave friendship, but were not doing it as a way to justify our lives and control the universe, instead we can do it as part of God's creation and living out His purpose.

Typecasting from worldly to redeemed in Christ is immediate, but painful. Imagine all those errors when the familiar calls are made to old functions which have disappeared. Errors, breaking, failure. But God is the error handling for this, we are an emulated process now executing inside His structure, and bad calls can be handled. He is our nanny process, our host system, our hypervisor.

~~~

I think there is an interesting caveat to the change in function calls though, because we can still make the old ones. Just because we aren't obliged to sin, it doesn't mean we can't choose it. Freedom in this model means that we could continue in the way we had been acting, with God insulating us from the damages caused when we try to execute a bad command. Or maybe he would let it execute as we expect, let us experience whatever the pain is that is coming, but ultimately if we're "in Him" then it won't permanently destroy us. 

It's a strange concept to try and put to programming since it's more our choice than normal programmatic flow. But I look at it a bit like badly bodged together wrapper scripts, which lets bad code limp on for years, with more and more layers of cruft added, or taking the better steps to rewrite the system and make it work properly.

Let's build on that idea. A very popular concept within the world of agile programming is this whole "launch and iterate" model. What would that look like for the human? How do we iterate? Well, if we're convinced that the old way of functioning is sufficient and everything around us must bend to our desires, then we are just adding more and more layers of abstraction. And with more layers between us and others, we're making more complicated scenarios which are bound to breakdown at some point. There will always be an edge case that will break these makeshift interfaces.

So let's say we rework the system. This means, as people, we change ourselves. It's hard. It admits we're imperfect, and often it hurts. You go through the same debugging steps, finding the things that used to work that don't anymore and you have to repair them. And sometimes you find the way you did it previously was just horribly dysfunctional, and can be significantly improved. So you refactor, and you improve yourself.

And you'll probably find others still need those cumbersome layers of abstraction to interact with you, or sometimes they just don't know how to handle the new data coming at them. But one thing you definitely learn from this model is that you can't change the other object! Imagine how much that changes our normal ways of social difficulty. As people, myself included, tend to see all problems as being the fault of those around me. Someone else caused this issue, if only they interacted MY way this never would have happened. Those thoughts are from us looking at the world as something that needs to be modified to fit our limited commands. Not that we ought to change to better interact with the world.

~~~

So merging these back together, I picture inheritance as the immediate change over from being stuck with one functional model, and moving to a much more versatile one. The one that inherits from a much better, more capable model, which is Jesus. And then the process of sanctification is where we launch an iterate on our own being. We wrestle with how we act, what we want, what we do, why we do it, and find that we're slowly reshaping our actions from "why can't everyone conform to me?" and into "how can I help others and interact better?"

And as a bonus, under the second model, we're no longer constantly angered by others not matching what we want, because we're sharing in the burden of communication.

Wednesday, April 15, 2015

Behind the name "Object-Oriented Faith"



I imagine there are two common reactions to the title of this blog. Those who might have some background in religions might think it is a reference to worshiped objects like idols, images, statues, things found in nature or made by people as gods and believed to contain power or act as power conduits. This is not what object-oriented means.

It is programming terminology.

Which brings me to the second reaction. Those who know programming, are probably wondering what faith has to do with programming. Programming is a strict logic system, and not something you would associate faith with. Faith tends to imply a belief that is unverified, and programming, like mathematics, is derived from repeated testing yielding the same results. It is no stretch of the imagination to say most would find these two incongruous.

So then, what is this amalgam of two seemingly unrelated terms? Let's borrow a quote from Wikipedia.

To quote Wikipedia:
"Object-oriented programming (OOP) is a programming paradigm based on the concept of "objects", which are data structures that contain data, in the form of fields, often known as attributes; and code, in the form of procedures, often known as methods A distinguishing feature of objects is that an object's procedures can access and often modify the data fields of the object with which they are associated (objects have a notion of "this"). In object-oriented programming, computer programs are designed by making them out of objects that interact with one another."

I am someone who relates well to code, and uses code to approximate life concepts, I felt that an object-oriented approach to faith would be a good idea. This isn't to say all concepts are easily coterminous with programming, but there's certainly some ideas that I have benefited from wrapping in that mindset.

To borrow phrasing from C.S. Lewis' Mere Christanity:
"What they do when they want to explain the atom, or something of that sort, is to give you a description out of which you can make a mental picture. But then they warn you that this picture is not what the scientists actually believe. What the scientists believe is a mathematical formula. The pictures are there only to help you to understand the formula. They are not really true in the way the formula is; they do not give you the real thing but only something more or less like it. They are only meant to help, and if they do not help you can drop them. The thing itself cannot be pictured, it can only be expressed mathematically. We are in the same boat here."

I really enjoy the object concepts. Objective interaction helps me picture God to me, me to others, and me to my body. There are countless ways that we interact, and what those interactions do, and I picture them like programs. When used properly, the system runs beautifully.

But more often, we get mismatches, we try the wrong call, and we break. We are broken people, and just as a program crashes, we fall apart in exciting and unexpected ways. Debugging the system, if you will, is the introspective guise I'm taking for this blog, as we delve into Christianity as a set of concepts and how they relate to each other.