G?d-talk is doubletalk, in Java
Feb. 7th, 2007 12:35 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
Since everyone else* I know seems to be writing about this, I guess it's my turn:
If you believe, as I do, that the world is made of stuff, which is arranged in patterns in space and time, that the patterns obey laws, and that there is no other stuff which can affect these patterns other than the aforementioned stuff, and you also talk G!d-talk, then your G?d-talk is doubletalk.
Doubletalk not because it is false — it's very true, in its way — but because most of the G!d-talk we hear around these parts has a certain general form, which has a certain most obvious interpretation in terms of what those sorts of words generally mean when they are used elsewhere, and that is not what you mean by your G!d-talk.
Mostly, when people use G!d-talk, they are using it for certain implications which the vernacular interpretation (where G!d is a big Person) shares with the more metaphorical view which I (and many of you, apparently) hold. However, a lot of people seem to get bothered when told that this means it mostly doesn't matter how you interpret their G!d-talk — they really want you to interpret it the way they do. I will now explain why I think that's silly, using the following Kabbalistic Java program:
There's a lot of theology packed into this snippet of code (not pesudocode — if you translate all the Hebrew keywords back to Java (and implement the proprietary Olam class, good luck with that!), it should compile), so I'll start by considering the question raised above: why is it silly to care about the metaphysics underlying someone else's interpretation of G?d-talk? It's silly because all we need to know about our G!d-concept (i.e. object reference) is that it implements Elohim — we don't need to know how (which is convenient, because we are unlikely to ever find out). In object-oriented programming, this notion that you shouldn't need to know how something works in order to relate to it is called "encapsulation". It is devoutly to be hoped that we don't need to know how G?d works in order to relate to G!d.
Here are a few other theological tidbits (although these are not conclusions, because they represent implementation decisions that could go either way, whereas encapsulation is really quite important):
Why call Olam's constructor at every time step, rather than calling a method to update haOlam in place? Because G!d "renews the work of creation continually every day" (that's from the Hebrew morning liturgy).
Why pass zot (this, G!d's self) as an argument to Olam()? So G!d can be present in the world — in particular, since nothing (that we can know about) happens outside of calls to Olam(), this is necessary for us to be in relationship with the divine. Kabbalists sometimes refer to G!d's Shechinah (presence) as zot in order to call attention to the fact that all we can know about ultimate reality is that it is right there, wherever you point. You may be familiar with the alternative belief that zot is not passed to Olam(), under the name "Deism".
As an also-pagan Jew, I feel that it's appropriate to refer to the one G1d by a multiplicity of names (including, if due care is taken, deity-names from other cultures). In Java, I might write something like saraswati = (religions.hinduism.Saraswati)elohai (elohai = "my god", which is a reference to the singleton instance of Hashem). This code would be in one of my personal methods, such as Ben.dabbleInHinduism(). The point being that saraswati and elohai are references to the same "object", but may have different interfaces, which pretty well captures my feelings, as a pagan Jew, about "other" deities.
Of course, there are others who have used programming language theory to talk about theology before, but I'm generally of the opinion that they didn't go nearly far enough. ;-)
* link to another user's friends-locked post
If you believe, as I do, that the world is made of stuff, which is arranged in patterns in space and time, that the patterns obey laws, and that there is no other stuff which can affect these patterns other than the aforementioned stuff, and you also talk G!d-talk, then your G?d-talk is doubletalk.
Doubletalk not because it is false — it's very true, in its way — but because most of the G!d-talk we hear around these parts has a certain general form, which has a certain most obvious interpretation in terms of what those sorts of words generally mean when they are used elsewhere, and that is not what you mean by your G!d-talk.
Mostly, when people use G!d-talk, they are using it for certain implications which the vernacular interpretation (where G!d is a big Person) shares with the more metaphorical view which I (and many of you, apparently) hold. However, a lot of people seem to get bothered when told that this means it mostly doesn't matter how you interpret their G!d-talk — they really want you to interpret it the way they do. I will now explain why I think that's silly, using the following Kabbalistic Java program:
echad class Hashem implements Elohim { sod class Olam { // secret! } sod Olam bereishit() { return yhi Olam(zot, tohu, vohu) } sod Olam chadesh(Olam haOlam) { return yhi Olam(zot, haOlam) } // various other methods, public and private }(For the Jewishly uninitiated:
- Elohim = "god"
- Hashem = the Name of G!d
- echad = "unique" (singleton)
- olam = "universe" (and ha- = "the")
- sod = "secret" (private) bereishit = "creation"
- yhi = "let there be" (new)
- tohu = "formless" (null) and vohu = "void" (0)
- chadesh = "renew"
- zot = "this" (this)
There's a lot of theology packed into this snippet of code (not pesudocode — if you translate all the Hebrew keywords back to Java (and implement the proprietary Olam class, good luck with that!), it should compile), so I'll start by considering the question raised above: why is it silly to care about the metaphysics underlying someone else's interpretation of G?d-talk? It's silly because all we need to know about our G!d-concept (i.e. object reference) is that it implements Elohim — we don't need to know how (which is convenient, because we are unlikely to ever find out). In object-oriented programming, this notion that you shouldn't need to know how something works in order to relate to it is called "encapsulation". It is devoutly to be hoped that we don't need to know how G?d works in order to relate to G!d.
Here are a few other theological tidbits (although these are not conclusions, because they represent implementation decisions that could go either way, whereas encapsulation is really quite important):
Why call Olam's constructor at every time step, rather than calling a method to update haOlam in place? Because G!d "renews the work of creation continually every day" (that's from the Hebrew morning liturgy).
Why pass zot (this, G!d's self) as an argument to Olam()? So G!d can be present in the world — in particular, since nothing (that we can know about) happens outside of calls to Olam(), this is necessary for us to be in relationship with the divine. Kabbalists sometimes refer to G!d's Shechinah (presence) as zot in order to call attention to the fact that all we can know about ultimate reality is that it is right there, wherever you point. You may be familiar with the alternative belief that zot is not passed to Olam(), under the name "Deism".
As an also-pagan Jew, I feel that it's appropriate to refer to the one G1d by a multiplicity of names (including, if due care is taken, deity-names from other cultures). In Java, I might write something like saraswati = (religions.hinduism.Saraswati)elohai (elohai = "my god", which is a reference to the singleton instance of Hashem). This code would be in one of my personal methods, such as Ben.dabbleInHinduism(). The point being that saraswati and elohai are references to the same "object", but may have different interfaces, which pretty well captures my feelings, as a pagan Jew, about "other" deities.
Of course, there are others who have used programming language theory to talk about theology before, but I'm generally of the opinion that they didn't go nearly far enough. ;-)
* link to another user's friends-locked post
(no subject)
Date: 2007-02-07 07:10 pm (UTC)(no subject)
Date: 2007-02-07 07:57 pm (UTC)