Just found your channel today, and I've liked all your posts -- including this one. (I didn't click the like button on every one, tho', so I also /haven't/ liked all of them. No contradiction there.)
I actually use the example of a Car when I talk in class about reference and co-reference -- the one car that belongs to both my wife and me, and a separate car with the same make, model, year and colour owned by my neighbour Jennifer down the street. Even picked the same six properties, and used Q4 for the .equals method. And I relate it to the polysemous question "Do I have the same car as her?" to motivate the distinction between == and .equals.
So I'm quite taken with your articles. But I'm not sure your strategy for resolving paradoxes works. Consider Russell's paradox. If I create a Set of Object in Java, I can add itself to itself:
Set<Object> theSet = new HashSet<>();
System.out.println(containsItself(theSet)); // prints "false"
theSet.add(theSet);
System.out.println(containsItself(theSet)); // prints "true"
I can use a foreach loop (or .stream().anyMatch(...)) in the method to find if a set contains itself:
public static boolean containsItself(Set<Object> givenSet) {
for (Object anElement : givenSet) {
if (anElement == givenSet) {
return true;
}
}
return false;
}
There is only one object involved here -- the HashSet instance that theSet, givenSet and anElement all refer to. There is no "carbon copy" of the set; there is no distinct "version" of the set inside the set. The == operator determines that givenSet and anElement are referencing the same object -- pointing at the same hunk of memory. It doesn't even look at the HashSet's properties. It doesn't dereference the variables.
The code needs two variables so that the programmer can specify the two roles it needs to play (content and container), but neither /variable/ contains an object. Each variable contains a /reference/ to the object -- a way of talking about (or to) that object. If my wife gets her car painted green, then my car will be green (her car == my car), but Jennifer's car will still be red (my car != her car). If I add my car to theSet (i.e. the object I'm talking about when I use that variable), then the set that theSet contains will also contain my car, because it's the object that contains (and is contained), not the variable.
So the metaphysics of Java allows a set to contain itself -- not just a copy of itself. Which suggests that your method for resolving paradoxes doesn't apply in that metaphysics.
An even simpler example, without the content/container distinction:
You can totally self-reference given certain equivalence criteria. When I say "you can't actually self-reference" I'm being a bit sloppy -- what I mean is that there are some equivalence criteria we can opt to use that are left unsatisfied whenever we attempt to refer to oneself.
Let's say we externalize referring as an action -- "Arrange," taking 4 parameters: A Shelf integer, a Target object, an Above pointer, and a Below pointer. The Above and Below pointers are assigned to the Target's own Above and Below properties, and the Shelf properties of the Above and Below objects pointed-at are assigned Shelf-1 and Shelf+1 respectively, while Shelf property of the Target is assigned Shelf.
We call this function with a Shelf of 5, a Target object, Above of null, and Below pointing to the Target. But there's a problem: What Shelf is it assigned? It's the Target, so it should be assigned to Shelf, but it's also the object pointed-at by Below, and the function wants to assign that to Shelf+1.
Now, of course, what the problem WILL do depends on which order we make these assignments, and the later one will stomp the earlier. But in the "metaprogram," the design, "the design wants to do one thing to this object" and "the design wants to do a different thing to this object" can be seen as two different, mutually exclusive qualities an object can have. In other words, "object, whereby the design wants to put it on Shelf 5" and "object, whereby the design wants to put it on Shelf 6" are two different object identities by this framing. And one of these identities must perish; whichever one was manifest first will die to the second.
This may all seem arbitrary, and it is in many ways, but we know some classic dangers of using "I don't care where I am in the strata" framings, like recursion that never comes home. We solve these cases by using carbon copies and having some sort of tracking, which can be seen as a different nametag and/or condition constituting distinct identities for each stratum.
Note that this is using a very "high-maintenance" understanding of numerical identity that requires absolute equivocality -- "anything that can be said about the one can rightly be said about the other." This does some weird things like making "Clark Kent, who is not Superman" as a different identity than "Clark Kent, who is also Superman," only the former of which Lois has in mind, even though both identities share the same atoms and whatnot.
But the payoffs are there. By insisting on absolute equivocality across every use case and every framing, we lock out these paradoxes. And the reverse is also true: By locking out certain use cases and framings, we can loosen up our standards of equivalence enough to invent any number of paradoxes.
You’re always not-you; everything, even in its relation to itself, is same but different. And, if you think about it, that’s why the liar paradox is the only true sentence (because it correctly asserts its own negation).
Just found your channel today, and I've liked all your posts -- including this one. (I didn't click the like button on every one, tho', so I also /haven't/ liked all of them. No contradiction there.)
I actually use the example of a Car when I talk in class about reference and co-reference -- the one car that belongs to both my wife and me, and a separate car with the same make, model, year and colour owned by my neighbour Jennifer down the street. Even picked the same six properties, and used Q4 for the .equals method. And I relate it to the polysemous question "Do I have the same car as her?" to motivate the distinction between == and .equals.
So I'm quite taken with your articles. But I'm not sure your strategy for resolving paradoxes works. Consider Russell's paradox. If I create a Set of Object in Java, I can add itself to itself:
Set<Object> theSet = new HashSet<>();
System.out.println(containsItself(theSet)); // prints "false"
theSet.add(theSet);
System.out.println(containsItself(theSet)); // prints "true"
I can use a foreach loop (or .stream().anyMatch(...)) in the method to find if a set contains itself:
public static boolean containsItself(Set<Object> givenSet) {
for (Object anElement : givenSet) {
if (anElement == givenSet) {
return true;
}
}
return false;
}
There is only one object involved here -- the HashSet instance that theSet, givenSet and anElement all refer to. There is no "carbon copy" of the set; there is no distinct "version" of the set inside the set. The == operator determines that givenSet and anElement are referencing the same object -- pointing at the same hunk of memory. It doesn't even look at the HashSet's properties. It doesn't dereference the variables.
The code needs two variables so that the programmer can specify the two roles it needs to play (content and container), but neither /variable/ contains an object. Each variable contains a /reference/ to the object -- a way of talking about (or to) that object. If my wife gets her car painted green, then my car will be green (her car == my car), but Jennifer's car will still be red (my car != her car). If I add my car to theSet (i.e. the object I'm talking about when I use that variable), then the set that theSet contains will also contain my car, because it's the object that contains (and is contained), not the variable.
So the metaphysics of Java allows a set to contain itself -- not just a copy of itself. Which suggests that your method for resolving paradoxes doesn't apply in that metaphysics.
An even simpler example, without the content/container distinction:
public class SelfReferencer {
public final SelfReferencer me = this;
}
You can totally self-reference given certain equivalence criteria. When I say "you can't actually self-reference" I'm being a bit sloppy -- what I mean is that there are some equivalence criteria we can opt to use that are left unsatisfied whenever we attempt to refer to oneself.
Let's say we externalize referring as an action -- "Arrange," taking 4 parameters: A Shelf integer, a Target object, an Above pointer, and a Below pointer. The Above and Below pointers are assigned to the Target's own Above and Below properties, and the Shelf properties of the Above and Below objects pointed-at are assigned Shelf-1 and Shelf+1 respectively, while Shelf property of the Target is assigned Shelf.
We call this function with a Shelf of 5, a Target object, Above of null, and Below pointing to the Target. But there's a problem: What Shelf is it assigned? It's the Target, so it should be assigned to Shelf, but it's also the object pointed-at by Below, and the function wants to assign that to Shelf+1.
Now, of course, what the problem WILL do depends on which order we make these assignments, and the later one will stomp the earlier. But in the "metaprogram," the design, "the design wants to do one thing to this object" and "the design wants to do a different thing to this object" can be seen as two different, mutually exclusive qualities an object can have. In other words, "object, whereby the design wants to put it on Shelf 5" and "object, whereby the design wants to put it on Shelf 6" are two different object identities by this framing. And one of these identities must perish; whichever one was manifest first will die to the second.
This may all seem arbitrary, and it is in many ways, but we know some classic dangers of using "I don't care where I am in the strata" framings, like recursion that never comes home. We solve these cases by using carbon copies and having some sort of tracking, which can be seen as a different nametag and/or condition constituting distinct identities for each stratum.
Note that this is using a very "high-maintenance" understanding of numerical identity that requires absolute equivocality -- "anything that can be said about the one can rightly be said about the other." This does some weird things like making "Clark Kent, who is not Superman" as a different identity than "Clark Kent, who is also Superman," only the former of which Lois has in mind, even though both identities share the same atoms and whatnot.
But the payoffs are there. By insisting on absolute equivocality across every use case and every framing, we lock out these paradoxes. And the reverse is also true: By locking out certain use cases and framings, we can loosen up our standards of equivalence enough to invent any number of paradoxes.
Thanks for sharing, Stan. You know I always enjoy your thoughts.
You’re always not-you; everything, even in its relation to itself, is same but different. And, if you think about it, that’s why the liar paradox is the only true sentence (because it correctly asserts its own negation).