I recently came to one of those incredibly simple conclusions (in hindsight) that nonetheless I think will help creating a better conceptual model (and ultimately a better formal model) of many notions in the physics of software.
You probably remember Newton’s Third Law of motion: when one body exerts a force on a second body, the second body simultaneously exerts a force equal in magnitude and opposite in direction on the first body. This is often called action-reaction. The two forces actually happens simultaneously.
Even outside motion laws, most physical phenomena are still based on the idea that you apply a force / differential / stimulus / whatever and something happens pretty much instantaneously as a direct consequence. You apply a difference of potential to a conductor, and you have current flowing according to Ohm’s law. You apply electrostatic charges to a couple of bodies, and a force (of interaction) appears as a direct consequence, according to Coulomb’s law. We come to expect this sort of stimulus -> response relationship to be direct and in many cases immediate (on a human scale).
There are, of course, cases where the more macroscopic phenomenon is not immediate, although it’s still a direct consequence of the stimulus. If you add heat to water, it stays liquid until the boiling point is reached. But of course that’s just one macroscopic view. At a different level, temperature is still increasing as a direct consequence of adding heat up to the boiling point. You do more of the same, and then a phase transition also happens.
Oversimplifying things to the point that I’m bordering on being wrong :-), I could say that by and large (but not always, see later) our models of the physical world are based on a direct Stimulus -> Response relationship (sometimes extremely complex, but still direct).
This does not translate well to the physics of software, which is probably why we get many expectations wrong (it does not conform to “naïve physics” expectations about how things work in our universe).
In software, you apply a stimulus and in most cases nothing noticeable happens. (Yes, I may have said otherwise before. I was imprecise. Read on for a better model.) You duplicate code. Nothing really happens. You keep duplicating. Nothing happens. You map an open set into a single artifact through a more or less glorified switch/case. Nothing happens.
Nothing happens until the next relevant event. You change a decision embodied in the code you’ve duplicated. Now you have to change all the copies. You add an entry to the open set. Now your artifact grows bigger.
Following this observation, the physics of software is better modeled as Stimulus -> Trigger -> Response. That is, if you apply a force (as I tend to call any kind of stimulus, waiting for a better term), and in most cases nothing happens as an immediate effect. It’s only when a subsequent event (trigger) happens that you get a specific response – possibly in a distant future, maybe never.
That’s why most non-functional properties are potentials. They’re the result of a stimulus, waiting for an event to happen.
Note: some chemical processes work in a similar way. You mix nitric acid and glycerin, and if you’re careful enough, nothing noticeable happens but a lot of potential energy is accumulated. The energy is released when triggered (for instance by a mechanical shock). So, in a sense, software is like explosives :-).
A more precise model
[This section might be hard to follow if you don’t have a good grasp of the difference between the essential interpreter of code (the computer) and the contingent interpreter (the human). Unfortunately I don’t have any introductory material. Sorry for that. See Gabriel and also some ideas in a previous random note of mine. If it sounds “wrong”, there is a chance that we’re not really understanding each other here.]
Let’s say that our models of the physical world (oversimplified as above) are based on a function Stimulus -> Response. According to the above, phenomena in the physics of software would be better modeled by a function (Stimulus, Trigger) -> Response. As the (contingent) interpreter of reality, we see a separation in time between Stimulus and Trigger, and therefore we tend to mentally curry the function. We apply a stimulus, and by doing so we set up our artifact to become, de facto, a function from Trigger to Response (do not mistake this as the function encoded into the artifact, to be executed by the essential interpreter [the computer]; I’m talking about the function as seen by the human contingent interpreter, or the function encoded in the shape of the artifact). In fact, a potential is exactly that: the ability to do something when triggered.
This model is still imprecise, in that is capturing only part of the reality; it might be more than adequate in some cases, but if we’re after a general form that can capture most phenomena in the physics of software, we need to cater for the (less apparent) immediate reaction as well.
Why do people duplicate code? Well, many reasons, but one is that it’s the path of least energy. Energy spent immediately, not later on. Therefore there must be a resisting force when we do something else, a force that makes us waste more energy. That’s happening immediately, so it’s not captured in the model above, and it’s in fact closer to what happens in the physical world.
So a more comprehensive model for most phenomena in the physics of software would be a function like:
Stimulus -> ( Immediate Response, Trigger -> Potential Response )
Stimulus and Triggers originate in the decision space. It is possible that we may have to model a number of immediate and potential responses, in which case a trivial extension of the model would be
Stimulus -> ( { Immediate Response }, Trigger -> { Potential Response } )
Phenomena in the physics of software should therefore be simply pairs in the domain / codomain of such function, like:
(Artifact cloned, ( { low resistance, U/U entanglement }, { (Update, { Scattered Update } ) } )
[where the function Trigger -> { Potential Response } is represented extensionally]
That’s expressing the idea that if you clone artifact, the immediate response is that you get low resistance and Update/Update entanglement between clones, and when triggered by an update in one artifact, you get a scattered update to all the U/U entangled clones.
I think this better model will become useful as I try to bring more clarity into the work I’ve done so far and hopefully will provide a better foundation for future works.
As usual, I welcome your feedback. So far, the only person to whom I’ve told the story in real life has spent all his time trying to convince me that I was wrong, so maybe I am.
You probably remember Newton’s Third Law of motion: when one body exerts a force on a second body, the second body simultaneously exerts a force equal in magnitude and opposite in direction on the first body. This is often called action-reaction. The two forces actually happens simultaneously.
Even outside motion laws, most physical phenomena are still based on the idea that you apply a force / differential / stimulus / whatever and something happens pretty much instantaneously as a direct consequence. You apply a difference of potential to a conductor, and you have current flowing according to Ohm’s law. You apply electrostatic charges to a couple of bodies, and a force (of interaction) appears as a direct consequence, according to Coulomb’s law. We come to expect this sort of stimulus -> response relationship to be direct and in many cases immediate (on a human scale).
There are, of course, cases where the more macroscopic phenomenon is not immediate, although it’s still a direct consequence of the stimulus. If you add heat to water, it stays liquid until the boiling point is reached. But of course that’s just one macroscopic view. At a different level, temperature is still increasing as a direct consequence of adding heat up to the boiling point. You do more of the same, and then a phase transition also happens.
Oversimplifying things to the point that I’m bordering on being wrong :-), I could say that by and large (but not always, see later) our models of the physical world are based on a direct Stimulus -> Response relationship (sometimes extremely complex, but still direct).
This does not translate well to the physics of software, which is probably why we get many expectations wrong (it does not conform to “naïve physics” expectations about how things work in our universe).
In software, you apply a stimulus and in most cases nothing noticeable happens. (Yes, I may have said otherwise before. I was imprecise. Read on for a better model.) You duplicate code. Nothing really happens. You keep duplicating. Nothing happens. You map an open set into a single artifact through a more or less glorified switch/case. Nothing happens.
Nothing happens until the next relevant event. You change a decision embodied in the code you’ve duplicated. Now you have to change all the copies. You add an entry to the open set. Now your artifact grows bigger.
Following this observation, the physics of software is better modeled as Stimulus -> Trigger -> Response. That is, if you apply a force (as I tend to call any kind of stimulus, waiting for a better term), and in most cases nothing happens as an immediate effect. It’s only when a subsequent event (trigger) happens that you get a specific response – possibly in a distant future, maybe never.
That’s why most non-functional properties are potentials. They’re the result of a stimulus, waiting for an event to happen.
Note: some chemical processes work in a similar way. You mix nitric acid and glycerin, and if you’re careful enough, nothing noticeable happens but a lot of potential energy is accumulated. The energy is released when triggered (for instance by a mechanical shock). So, in a sense, software is like explosives :-).
A more precise model
[This section might be hard to follow if you don’t have a good grasp of the difference between the essential interpreter of code (the computer) and the contingent interpreter (the human). Unfortunately I don’t have any introductory material. Sorry for that. See Gabriel and also some ideas in a previous random note of mine. If it sounds “wrong”, there is a chance that we’re not really understanding each other here.]
Let’s say that our models of the physical world (oversimplified as above) are based on a function Stimulus -> Response. According to the above, phenomena in the physics of software would be better modeled by a function (Stimulus, Trigger) -> Response. As the (contingent) interpreter of reality, we see a separation in time between Stimulus and Trigger, and therefore we tend to mentally curry the function. We apply a stimulus, and by doing so we set up our artifact to become, de facto, a function from Trigger to Response (do not mistake this as the function encoded into the artifact, to be executed by the essential interpreter [the computer]; I’m talking about the function as seen by the human contingent interpreter, or the function encoded in the shape of the artifact). In fact, a potential is exactly that: the ability to do something when triggered.
This model is still imprecise, in that is capturing only part of the reality; it might be more than adequate in some cases, but if we’re after a general form that can capture most phenomena in the physics of software, we need to cater for the (less apparent) immediate reaction as well.
Why do people duplicate code? Well, many reasons, but one is that it’s the path of least energy. Energy spent immediately, not later on. Therefore there must be a resisting force when we do something else, a force that makes us waste more energy. That’s happening immediately, so it’s not captured in the model above, and it’s in fact closer to what happens in the physical world.
So a more comprehensive model for most phenomena in the physics of software would be a function like:
Stimulus -> ( Immediate Response, Trigger -> Potential Response )
Stimulus and Triggers originate in the decision space. It is possible that we may have to model a number of immediate and potential responses, in which case a trivial extension of the model would be
Stimulus -> ( { Immediate Response }, Trigger -> { Potential Response } )
Phenomena in the physics of software should therefore be simply pairs in the domain / codomain of such function, like:
(Artifact cloned, ( { low resistance, U/U entanglement }, { (Update, { Scattered Update } ) } )
[where the function Trigger -> { Potential Response } is represented extensionally]
That’s expressing the idea that if you clone artifact, the immediate response is that you get low resistance and Update/Update entanglement between clones, and when triggered by an update in one artifact, you get a scattered update to all the U/U entangled clones.
I think this better model will become useful as I try to bring more clarity into the work I’ve done so far and hopefully will provide a better foundation for future works.
As usual, I welcome your feedback. So far, the only person to whom I’ve told the story in real life has spent all his time trying to convince me that I was wrong, so maybe I am.
RSS Feed
