Sunday, February 17, 2008
Garbage Collecting Thingyness
Hopefully most people who read the title for this post will immediately think to themselves, "Thingyness is a made-up word for a made-up idea. Thingyness doesn't even exist!" If you fall into that camp, you can stop reading after this first paragraph, since that's pretty much all I'm trying to say. Thinking of a particular slice of the spacetime continuum as a "thing" may be a useful convention for everyday life, but hardly a rigorous scientific concept.
This is not a new idea I'm proposing. One afternoon not long ago, I found myself at the end of a long trail of clicks in Wikipedia, staring at the Sorites paradox, thinking "gosh, the Greek word for heap is the same as the last name of George Soros." The Sorites paradox, for those who were able to resist clicking through to Wikipedia, is part of a long and glorious tradition of identity paradoxes. If you have a heap of sand, and take away the grains of sand one by one, when does it stop being a heap? Imagine you pile them all into a new location- when does the new location begin to be a heap?
Another such paradox is called the ship of Theseus. Guy Theseus gets on a boat for a long trip. Boat decays (as boats and other things are wont to do), and Theseus replaces various planks, oars, masts, keels, etc., until none of the original parts are left. Is it still the same boat?
Programmers, as it turns out, lack such a paradox. It's not that programmers are so smart, but rather that identity is a more rigorously defined concept. In a software program, every value can be represented by a string of bits. Strings of bits can be compared to other strings of bits for equality. If each bit in the string is the same as each bit in another string, they are equal. If a single bit differs, they are not equal.
Pretty simple.
Programmers are also accustomed to defining a very specific number of bits at a very specific location for analysis, and subsequently re-using that same location for an entirely different purpose (understanding that the re-use must be done quite explicitly). Thus, in the case of the Sorites paradox, a programmer might say "This memory location is for a heap. In each part of the heap, there may be either sand or air. When there is no longer a need for the heap, re-allocate this memory location to be used for storing something else."
The three variables the programmer needs to track are the memory location, memory size, and memory scope. Scope is basically a programmers way of defining when to start and when to stop using the memory at a particular location. By this point it should be clear even to non-programmers why programmers are un-troubled by identity paradoxes.
There are however, some strange nuances to this lack of paradox.
For instance, a particular location in memory may be used to store a letter, which in turn gets used as a number or a color or a pointer to a different location in memory, depending upon the context. As an example, the letter "A" is often stored as the binary value 00101001. That binary value also corresponds to the number 41 in decimal. If you increase the decimal value 41 to 42 (viewing the value as a number) it will then have the binary representation 00101010, which in turn corresponds to the letter B.
That's not too counter-intuitive- the letter B does, after all, follow the letter A.
But what about this: in the same encoding (known as "ASCII"), if you take the number 42 and add twenty, you get the number 62, which can be encoded in binary as 00111110. That corresponds with the letter b. E.g. the lower-case version of B.
Adding 20 to a number seems like a weird operation to make it lowercase, but that's the kind of trick that programmers do all the time. It would also be totally normal to view the letter B as a color (or at least a grayscale value) in a different context. The Processing language that I've discussed elsewhere on this site does so.
What does it all mean?
Well, the answer is, I don't really know what it all means. However, I do suspect that computer programming provides us with a reasonably sound philosophical tool that may assist us in untangling identity paradoxes and other possibly thorny issues that arise with our every-day mode of non-rigorous thinking. Maybe paradoxes like these ones are best handled by asking some of the questions programmers ask all the time:
Even if it doesn't help untangle paradoxes any better, it will make us all bigger nerds, which is always a good thing.
This is not a new idea I'm proposing. One afternoon not long ago, I found myself at the end of a long trail of clicks in Wikipedia, staring at the Sorites paradox, thinking "gosh, the Greek word for heap is the same as the last name of George Soros." The Sorites paradox, for those who were able to resist clicking through to Wikipedia, is part of a long and glorious tradition of identity paradoxes. If you have a heap of sand, and take away the grains of sand one by one, when does it stop being a heap? Imagine you pile them all into a new location- when does the new location begin to be a heap?
Another such paradox is called the ship of Theseus. Guy Theseus gets on a boat for a long trip. Boat decays (as boats and other things are wont to do), and Theseus replaces various planks, oars, masts, keels, etc., until none of the original parts are left. Is it still the same boat?
Programmers, as it turns out, lack such a paradox. It's not that programmers are so smart, but rather that identity is a more rigorously defined concept. In a software program, every value can be represented by a string of bits. Strings of bits can be compared to other strings of bits for equality. If each bit in the string is the same as each bit in another string, they are equal. If a single bit differs, they are not equal.
Pretty simple.
Programmers are also accustomed to defining a very specific number of bits at a very specific location for analysis, and subsequently re-using that same location for an entirely different purpose (understanding that the re-use must be done quite explicitly). Thus, in the case of the Sorites paradox, a programmer might say "This memory location is for a heap. In each part of the heap, there may be either sand or air. When there is no longer a need for the heap, re-allocate this memory location to be used for storing something else."
The three variables the programmer needs to track are the memory location, memory size, and memory scope. Scope is basically a programmers way of defining when to start and when to stop using the memory at a particular location. By this point it should be clear even to non-programmers why programmers are un-troubled by identity paradoxes.
There are however, some strange nuances to this lack of paradox.
For instance, a particular location in memory may be used to store a letter, which in turn gets used as a number or a color or a pointer to a different location in memory, depending upon the context. As an example, the letter "A" is often stored as the binary value 00101001. That binary value also corresponds to the number 41 in decimal. If you increase the decimal value 41 to 42 (viewing the value as a number) it will then have the binary representation 00101010, which in turn corresponds to the letter B.
That's not too counter-intuitive- the letter B does, after all, follow the letter A.
But what about this: in the same encoding (known as "ASCII"), if you take the number 42 and add twenty, you get the number 62, which can be encoded in binary as 00111110. That corresponds with the letter b. E.g. the lower-case version of B.
Adding 20 to a number seems like a weird operation to make it lowercase, but that's the kind of trick that programmers do all the time. It would also be totally normal to view the letter B as a color (or at least a grayscale value) in a different context. The Processing language that I've discussed elsewhere on this site does so.
What does it all mean?
Well, the answer is, I don't really know what it all means. However, I do suspect that computer programming provides us with a reasonably sound philosophical tool that may assist us in untangling identity paradoxes and other possibly thorny issues that arise with our every-day mode of non-rigorous thinking. Maybe paradoxes like these ones are best handled by asking some of the questions programmers ask all the time:
- What location in memory (or in spacetime) are we talking about?
- How is the location in memory being used in the program (or subjective reality)?
- When is it appropriate to re-allocate that location in memory for other uses?
Even if it doesn't help untangle paradoxes any better, it will make us all bigger nerds, which is always a good thing.
// posted by David @ 9:12 PM 
Subscribe to Posts [Atom]