Duality
Friday, 13. January 2006, 03:58:18
I've been doing some thinking lately. Yes, yes, quite amazing I know. But I was wondering about is the duality of code and data.
There is an obvious duality in nature and every aspect of our universe. Many religious and scientific texts alike mention this duality. But how does this relate to computers? Surely, computers are no exception to this duality. This is what got me to thinking. A dangerous excercise to be sure, but one that could possibly lead to interesting results.
We know the obvious duality of code vs. data. They are flip side of the same thing. Not all data can be treated as code however. But there is a duality there nonetheless. What other duality is there? Most instructions have an inverse operation. These are the same properties as mathematical operations. Add vs. subtract, multiply vs. divide, left shift vs. right shift, push vs. pop, load vs. store, etc.
Does it end there? Is there anything else about computers that has duality? Well, RAM can have the dual nature of simply being memory or being attached to a hardware device. This is not RAM per se, but the address space. Even for devices, there is a duality. Commands and Data ports. This is an extension of the code vs. data duality. Not only that, but the CPU can speak with the device just as the device can speak to the CPU via interrupts. This would be a duality of request and notification. This could also be an extension of the call vs. return duality. Already, we can see a supersymmetry developing.
So when we design higher level languages, should we not conform to this idea of supersymmetry and duality? Right now, I think we are fighting it. We have objects, but no standard way to specify notifications. Not that it can't be done, but it's not implicit in the design. Also, objects can send commands to each other without the intervention of the main program. More than that, there is no concept of a main program except at the "main" function. While computer devices can transfer data between each other automatically, they do not start this transfer on their own. The CPU must initialise it. I think this is an important component that is missing from current language design. While there can be standard methods of linking a GUI and input devices for example, this should be under the control of the main application so that it can modify the way this is done if need be. This would be especially useful for using normally incompatible "devices" or objects.
Are these crazy ideas that will only get me in trouble? Imagine if all objects were not allowed to talk to each other directly and were independant in their ability to process the data given to them. This would solve locking and threading in one fell swoop. Of course, programming in an asynchronous way is quite tedious. Not only that, but limiting inter-object communication would require more code to control these objects.
Yet, I can't help getting the feeling that there may be something of value there. I also like the idea that you could send an object a ton of data and then send a single command to have the object process all the data given to it. Currently with function calls, it's one thing at a time. Having a single interface for all objects would be weird, but could have serious advantages. You could use the same code for many different kinds of objects and additional functionality would be through the same channel.
Right now, we have the OS that takes care of all our hardware devices. Would taking this one extra step using supersymmetry be advisable? To specify a host of objects that your software will use as "resources" and then write software that will control these resources? Would that be a better way to do things? Currently, there is no "software" part or execution part. It's all objects or all functions.
Think about this. Say you have two objects that are interdependant and in current languages, you would simply pass one of them a reference to the other. If everything goes well then you're fine. But what happens if one of these objects fail? The other will necessarily fail also. However, with the "switchboard" paradigm, only one object will fail. The main execution thread will be notified of this failure and will have the chance to replace it with an alternative object and better yet, report this error to the user. In the old way, this was left to the object and most of the time with exceptions, this would cause a domino effect that could theoretically make your entire program fail.
These are ideas that crossed my mind today. Hope you enjoyed them. And if you've noticed, I'm looking for opinions as I don't have my mind made up on these issues yet. So for this particular discussion, I would much prefer your own personal thought. While I still don't mind links (and will gladly accept any you have), I would rather hear what *you* have to say for this discussion. As an exception, pardon the pun, I do want links on the switchboard supersymmetric duality paradigm or anything that resembles it. I couldn't find anything on it. Probably because no one's that crazy.
There is an obvious duality in nature and every aspect of our universe. Many religious and scientific texts alike mention this duality. But how does this relate to computers? Surely, computers are no exception to this duality. This is what got me to thinking. A dangerous excercise to be sure, but one that could possibly lead to interesting results.
We know the obvious duality of code vs. data. They are flip side of the same thing. Not all data can be treated as code however. But there is a duality there nonetheless. What other duality is there? Most instructions have an inverse operation. These are the same properties as mathematical operations. Add vs. subtract, multiply vs. divide, left shift vs. right shift, push vs. pop, load vs. store, etc.
Does it end there? Is there anything else about computers that has duality? Well, RAM can have the dual nature of simply being memory or being attached to a hardware device. This is not RAM per se, but the address space. Even for devices, there is a duality. Commands and Data ports. This is an extension of the code vs. data duality. Not only that, but the CPU can speak with the device just as the device can speak to the CPU via interrupts. This would be a duality of request and notification. This could also be an extension of the call vs. return duality. Already, we can see a supersymmetry developing.
So when we design higher level languages, should we not conform to this idea of supersymmetry and duality? Right now, I think we are fighting it. We have objects, but no standard way to specify notifications. Not that it can't be done, but it's not implicit in the design. Also, objects can send commands to each other without the intervention of the main program. More than that, there is no concept of a main program except at the "main" function. While computer devices can transfer data between each other automatically, they do not start this transfer on their own. The CPU must initialise it. I think this is an important component that is missing from current language design. While there can be standard methods of linking a GUI and input devices for example, this should be under the control of the main application so that it can modify the way this is done if need be. This would be especially useful for using normally incompatible "devices" or objects.
Are these crazy ideas that will only get me in trouble? Imagine if all objects were not allowed to talk to each other directly and were independant in their ability to process the data given to them. This would solve locking and threading in one fell swoop. Of course, programming in an asynchronous way is quite tedious. Not only that, but limiting inter-object communication would require more code to control these objects.
Yet, I can't help getting the feeling that there may be something of value there. I also like the idea that you could send an object a ton of data and then send a single command to have the object process all the data given to it. Currently with function calls, it's one thing at a time. Having a single interface for all objects would be weird, but could have serious advantages. You could use the same code for many different kinds of objects and additional functionality would be through the same channel.
Right now, we have the OS that takes care of all our hardware devices. Would taking this one extra step using supersymmetry be advisable? To specify a host of objects that your software will use as "resources" and then write software that will control these resources? Would that be a better way to do things? Currently, there is no "software" part or execution part. It's all objects or all functions.
Think about this. Say you have two objects that are interdependant and in current languages, you would simply pass one of them a reference to the other. If everything goes well then you're fine. But what happens if one of these objects fail? The other will necessarily fail also. However, with the "switchboard" paradigm, only one object will fail. The main execution thread will be notified of this failure and will have the chance to replace it with an alternative object and better yet, report this error to the user. In the old way, this was left to the object and most of the time with exceptions, this would cause a domino effect that could theoretically make your entire program fail.
These are ideas that crossed my mind today. Hope you enjoyed them. And if you've noticed, I'm looking for opinions as I don't have my mind made up on these issues yet. So for this particular discussion, I would much prefer your own personal thought. While I still don't mind links (and will gladly accept any you have), I would rather hear what *you* have to say for this discussion. As an exception, pardon the pun, I do want links on the switchboard supersymmetric duality paradigm or anything that resembles it. I couldn't find anything on it. Probably because no one's that crazy.
WIDGETIZE
Dan Kubb # 13. January 2006, 18:40
With REST there is a universal address syntax for describing a resource's location, the URI. Each resource exposes a uniform interface: GET, PUT, POST, DELETE, OPTIONS that are roughly equivalent to: read, write, append, delete and get allowed methods. Arguments are supplied to PUT and POST by passing in a message either describing the new state of the resource for PUT, or the state of the resource to create/append in the case of POST. The other methods just need the URI to perform an operation and do not accept any additional arguments.
I think you're right that having a single interface to objects would be a little weird, but I also agree that it could have some serious advantages. The web wouldn't work in its current form if every resource had its own interface. There would be alot more infrastructure necessary to describe what a resource can do and how to use it. I'd prefer to have resources be uniform and interchangeable and have to be a little more verbose in describing what I want state I want the resource to be in.