If you have read my limited Bio information, you may have noticed that I am a Software Engineer and also an ordained Anglican priest.
In seminary, one assignment was to write a letter to a fictional friend, explaining the Trinity in some creative imagery. The doctrine of the Holy Trinity is and to some extent has always been one of the more numinous and abstruse in Christianity.
My paper sought to use Object-Oriented concepts to shed light on this great mystery of faith. This is second in a series of posts that somewhat adapts that paper to this different forum, and to my understanding as it stands now of both the Trinity and Object-Oriented programming and design. The first part is found here.
Hi Christian! The last time I wrote, I used the Object-Oriented design pattern of the Singleton to look at the Trinity and its claim that God is One. But as you rightly point out in your reply, that barely scratched the surface of the doctrine of the Trinity. Let's go deeper.
When we say God is Trinity, we are saying not only that God is One but also that this one, particular God is also Three. This single, identifiable divine Being consists of three distinct entities, what Christians have traditionally called “Persons.” Our historic labels for these three are God the Father, God the Son and God the Holy Spirit. If the label “Person” causes grief, think of them as distinct beings or “independent realities.”
The first of these “Persons” is God the Father. Don't let the qualifier trip you up; it is not claiming a divine Male-ness. You could substitute God the Mother or God the Parent if you prefer, although those labels would not be well-received everywhere. God the First? God the Begetter? How's that for an old-fashioned word! But it comes closer to what the doctrine of Trinity is trying to communicate.
The name "God the Father" comes from the unique relationship with God the Son, who is the second “Person” in the Trinity. We use human parentage language - like begetting! - to say that the Son comes from the Father. We say that the Father “begets” the Son. A modern rephrasing might be that the Father “generates” the Son. From long habit, I will use God the Father in this letter, hope that's OK!
In our software world, it’s tempting to say that God the Father generating God the Son follows one of the creational design patterns.
For example, consider the Builder design pattern. In the Builder pattern, a client caller can request the construction of a complex object with minimal information - such as the class type and the content. All of the complexities of actually creating and initializing the object the Builder builds are hidden from the client.
Let's not worry about who or what would be the calling client that would trigger God the Builder to generate God the Son. It would not be us humans or any created thing. If you need a client, maybe think of it as a divine imperative triggering the Builder's actions, although I suspect theologians would call it more an act of God's free will.
No matter. Something sparks God the Father to generate God the Son, like the Builder class would create the complex Product object requested by the Client object, while protecting the client from the complexities involved. (And there certainly are complexities in the Trinity!)
But one flaw in this imagery is that, fundamentally, God the Father and God the Son are both of the same Class. A Builder does not make other Builders. The best software analogy for them both being the same class might be the Constructor method, which creates an instance of the same Class.
Not only that, this Builder pattern imagery sounds like a one-and-done action, something that happens just once, after which the thing is built. That can make us think that there was a time before the Son existed, that the Son once was not but that now he has been created.
This would make the Son a mere creature, however, and not divine. The doctrine of the Trinity insists that this begetting / begotten relationship is timeless and eternal; the Father is eternally generating the Son, to be like himself, that is, divine.
If God is a Singleton like we said last time, eternal generation might be like someone coding the God-Singleton to call its internal constructor on every external reference, rather than reusing the eternally-existing (from the caller's perspective) instance.
Whatever the label, it is to this first Person that we credit the creation of everything – you and me, plants and animals, stars and planets, and all matter and energy in the entire universe. Which of course is not like a Singleton or Factory or Builder design pattern. There may not be a good Software Development comparison for that! There is more we could say about the Trinity and Software Development, but I will stop here for now.
Peace,
Steve
In seminary, one assignment was to write a letter to a fictional friend, explaining the Trinity in some creative imagery. The doctrine of the Holy Trinity is and to some extent has always been one of the more numinous and abstruse in Christianity.
My paper sought to use Object-Oriented concepts to shed light on this great mystery of faith. This is second in a series of posts that somewhat adapts that paper to this different forum, and to my understanding as it stands now of both the Trinity and Object-Oriented programming and design. The first part is found here.
Hi Christian! The last time I wrote, I used the Object-Oriented design pattern of the Singleton to look at the Trinity and its claim that God is One. But as you rightly point out in your reply, that barely scratched the surface of the doctrine of the Trinity. Let's go deeper.
When we say God is Trinity, we are saying not only that God is One but also that this one, particular God is also Three. This single, identifiable divine Being consists of three distinct entities, what Christians have traditionally called “Persons.” Our historic labels for these three are God the Father, God the Son and God the Holy Spirit. If the label “Person” causes grief, think of them as distinct beings or “independent realities.”
The first of these “Persons” is God the Father. Don't let the qualifier trip you up; it is not claiming a divine Male-ness. You could substitute God the Mother or God the Parent if you prefer, although those labels would not be well-received everywhere. God the First? God the Begetter? How's that for an old-fashioned word! But it comes closer to what the doctrine of Trinity is trying to communicate.
The name "God the Father" comes from the unique relationship with God the Son, who is the second “Person” in the Trinity. We use human parentage language - like begetting! - to say that the Son comes from the Father. We say that the Father “begets” the Son. A modern rephrasing might be that the Father “generates” the Son. From long habit, I will use God the Father in this letter, hope that's OK!
In our software world, it’s tempting to say that God the Father generating God the Son follows one of the creational design patterns.
For example, consider the Builder design pattern. In the Builder pattern, a client caller can request the construction of a complex object with minimal information - such as the class type and the content. All of the complexities of actually creating and initializing the object the Builder builds are hidden from the client.
Let's not worry about who or what would be the calling client that would trigger God the Builder to generate God the Son. It would not be us humans or any created thing. If you need a client, maybe think of it as a divine imperative triggering the Builder's actions, although I suspect theologians would call it more an act of God's free will.
No matter. Something sparks God the Father to generate God the Son, like the Builder class would create the complex Product object requested by the Client object, while protecting the client from the complexities involved. (And there certainly are complexities in the Trinity!)
But one flaw in this imagery is that, fundamentally, God the Father and God the Son are both of the same Class. A Builder does not make other Builders. The best software analogy for them both being the same class might be the Constructor method, which creates an instance of the same Class.
Not only that, this Builder pattern imagery sounds like a one-and-done action, something that happens just once, after which the thing is built. That can make us think that there was a time before the Son existed, that the Son once was not but that now he has been created.
This would make the Son a mere creature, however, and not divine. The doctrine of the Trinity insists that this begetting / begotten relationship is timeless and eternal; the Father is eternally generating the Son, to be like himself, that is, divine.
If God is a Singleton like we said last time, eternal generation might be like someone coding the God-Singleton to call its internal constructor on every external reference, rather than reusing the eternally-existing (from the caller's perspective) instance.
Whatever the label, it is to this first Person that we credit the creation of everything – you and me, plants and animals, stars and planets, and all matter and energy in the entire universe. Which of course is not like a Singleton or Factory or Builder design pattern. There may not be a good Software Development comparison for that! There is more we could say about the Trinity and Software Development, but I will stop here for now.
Peace,
Steve