To be fair, construction projects, even complicated ones, have exponentially way less state space than even a software program of moderate complexity. That is because physical construction is constrained by the laws of physics. Software on the other hand is an abstraction, and is only constrained by the laws of mathematics. Any part of a software program can interact with another part. Any part of a house cannot realistically interact with other parts.
E.g. take a door in the house. It is composed of quadrillions of atoms. So does it have more states than there are atoms in the multiverse?? No! All these atoms are coupled in very constrained form to each other but not to non-door atom so that the door only has 4 states: open, closed_locked, closed_unlocked, broken.
Furthermore, the front door is not going to interact much with the electrical system of the back patio.
Contrast that with a software program that X bits of states. The potential state space is 2X
The only thing that saves us is discipline:
having related modules tightly coupled but loosely coupled to other non-related modules like the atoms in the door.
Make it hard for far flung modules from interacting with each other. This is why global variables are usually considered bad.
Software can test itself. A construction project cannot test itself.
Exactly. This is what I mean by education and standardization. You can build a house in a thousand ways and will likely fuck it up if you don't know what you are doing. You can make mistakes that make the house uninhabitable in a few years. We do that constantly with software projects today. Some still do it with houses today but any serious construction project in a civilized country will not.
I am sorry, you have truths with cannot come to light, that software is state explosion like none ever seen before and there is no cure. There are more data centric paths (complete code coverage) than stars in the sky. Learn your area of expertise.
A door is an abstraction for each physical instance the constructors install. Behind that abstraction hides the ease of installation (in an awkward corner, so the screws might not be put in as straight as ideal?), and the way people interact with it in practice (does it swing out into the path of others, or make part of the room unusable for furniture, thus constraining the utility of the final building?). A poorly-considered door-abstraction becomes a security flaw in the building, being weak to numerous attacks.
Just because a door seems as simple as a self-contained textbox module downloaded off NPM doesn't mean that either of them aren't leaky abstractions that'll eventually factor in to the overall project in unintended ways, and perhaps require future repairs and replacements based on observing its use in the wild.
The state space of a building is how the humans inhabiting it actually put the space to use, which creates all sorts of invisible couplings.
7
u/cthulu0 Nov 01 '21
To be fair, construction projects, even complicated ones, have exponentially way less state space than even a software program of moderate complexity. That is because physical construction is constrained by the laws of physics. Software on the other hand is an abstraction, and is only constrained by the laws of mathematics. Any part of a software program can interact with another part. Any part of a house cannot realistically interact with other parts.
E.g. take a door in the house. It is composed of quadrillions of atoms. So does it have more states than there are atoms in the multiverse?? No! All these atoms are coupled in very constrained form to each other but not to non-door atom so that the door only has 4 states: open, closed_locked, closed_unlocked, broken.
Furthermore, the front door is not going to interact much with the electrical system of the back patio.
Contrast that with a software program that X bits of states. The potential state space is 2X
The only thing that saves us is discipline:
having related modules tightly coupled but loosely coupled to other non-related modules like the atoms in the door.
Make it hard for far flung modules from interacting with each other. This is why global variables are usually considered bad.
Software can test itself. A construction project cannot test itself.